freenode/#clim - IRC Chatlog
Search
4:06:03
loke
I need advice: What is the actual "proper" way to do animation in CLIM? My needs are simple: A few circles and lines needs to be redrawn so as to create an animation. I odn't even know if I should add these objects as output records and then change them, or do I do it on a lower level and take over the drawing altogether by overriding HANDLE-REPAINT?
4:06:35
loke
Doing it wih output records/presentations would be nice becuase of some interactivity features I'd get for free.
4:09:29
beach
I don't know the answer, but I would use the first method, i.e. use output records, and either modify them destructively or replace some of them.
4:16:28
loke
beach: Do you happen to know how I can force a repaint of the output records after modyfing them?
4:17:12
loke
I tried REDISPLAY-FRAME-PANE but that doesn't work. It only picks up the updates after going back to the command loop and typing a command
4:21:49
loke
Hmm... That means I have to store the output records somehow? Right now I just have a list of the presentations (one presentation for each graphical object on the screen)
4:23:15
loke
Yeah, or a hash map. I know which presentations have changed so I guess there is no need to repaint all the ones who doesn't change (unless they overlap)
7:06:39
loke
beach: I'm a bit confused now. I thought I understood this, but clearly not. I create output records using WITH-OUTPUT-TO-OUTPUT-RECORD. Then I add them to the pane using STREAM-ADD-OUTPUT-RECORD. The actual graphics are drawn (in the body of W-O-T-O-R) using STREAM-PRESENT, and the drawing happens in a presentation method for regular classes.
7:07:11
loke
The problem is when one of these regular classes are changed, am I supposed to remove the corresponding output record and create a new one?
7:44:09
beach
When I did this for Second Climacs, I just created my own classes, and manipulated them explicitly, rather than relying on ADD-OUTPUT-RECORD.
8:55:41
loke
beach: after I change an output record, I need to make sure that the old position is eventually redrawn. What's the proper way to handle that? I'd like to avoid repaining everything.
9:20:24
beach
Your questions make me more convinced than ever that we need a bottom-up McCLIM manual.
9:31:57
loke
Isn't there a region that is a set of other regions? I could add the enclosing rectangles of all the changed records and do a repaint.
9:47:40
loke
Now, about modification of output records. Can I create a special output record for which I can create a method that gets called every time the record should be drawn?
13:50:50
scymtym
jackdaniel: could you have a look at #1099? it is a small fix for an annoying regression
13:52:52
jackdaniel
random idea: when we realize a mirror on a sheet that is not grafted, should the mirror be a pixmap? (assuming that pixmaps /are/ off-screen mirrors)
14:19:22
scymtym
didn't you also want to set the port "late", that is when grafting the sheet? without a port, making the right kind of pixmap seems impossible
14:22:07
jackdaniel
mcclim core wont' call realize-mirror on its own either (it is prompted by note-sheet-grafted) -- I can imagine, that a programmer sets the port manually and calls realize-mirror
14:23:51
scymtym
maybe i'm not understanding the first proposal properly. how would the port normally be set?
14:31:22
loke
OK, I have a really weird problem... I will try to explain it here in the hope that make I make enough sense that someone may be able to give me a suggestion
14:49:08
jackdaniel
the proposal in #1103 is to call (setf (port sheet) (port graft)) when the sheet is grafted
14:53:09
jackdaniel
loke: adding the output record to a pane does not necessarily mean drawing it, you should call replay on that output record
14:54:33
scymtym
jackdaniel: ok, that confused me because setting the port, realizing the mirror (possibly as a pixmap) and (de)grafting would interact in more complicated ways than in the "normal" case where everything is tied to (de)grafting and the port doesn't change
14:54:49
loke
so when the outer record gets drawn (in REPLAY-OUTPUT-RECORD I guess), shouldn't it then call the child record recursively?
14:55:36
loke
And why does it work the first time but not the second time (after typing a command in the interactor)
14:55:37
jackdaniel
scymtym: when you realize the mirror manually (without grafting it first), then you also call destory-mirror manually (and you are not degrafting it)
14:56:44
jackdaniel
loke: if I understand you correctly, you add the output record from the replay function?
14:57:22
jackdaniel
as of why it is drawn during the first time - I don't know, but adding output records interwened with replying them sounds like an undefined behavior
14:57:37
scymtym
jackdaniel: sure, but the state space is more complicated. for example, if you set the port, then realize the mirror, then graft, will the port be changed and will pixmap mirror be destroyed? or will an error be signaled?
14:58:27
loke
The record is there. It works the first time, but the inner record doesn't get displayed the second time the REPAINT-ALL is called.
14:59:02
loke
However, the record is there, because if I call REPAINT-SHEET on the pane, all gets displayed.
14:59:04
jackdaniel
scymtym: I'd opt for signalling an error, i.e "sheet can't be grafted, it already has a mirror"
15:03:22
loke
It's really odd, because this principle of creating an output record and adding it is something Climaxima does everywhere, and I've never had this problem in other places.
15:04:01
jackdaniel
loke: you would have better chances if you had constructed a minimal example of code, that may be run
15:04:37
loke
jackdaniel: Yes, I will do that. It's a bit of a hassle though so I'm going to try some things first.
15:06:12
scymtym
loke: one option would be, after executing the command, run (clouseau:inspect climi::*all-ports*), the click through port » frame manager » frame » panes » output history and see whether the output record hierarchy looks correct
15:08:05
jackdaniel
scymtym: what should the backend do when realize-mirror is called on a sheet, that is not grafted?
15:10:26
loke
Interesting... I have two versions. One works, the other don't. As best as I can tell, they should be equivalent, no?
15:11:22
jackdaniel
acting only on the information you have provided (that one version works and one doesn't), I'd say that they are not equivalent ,-)
15:11:41
scymtym
jackdaniel: i thought that case didn't arise currently since grafting and REALIZE-MIRROR are tied together