Again display updates of SPGroups and their children
Hi all,
I've asked this before but unfortunately I haven't been able to fix it yet. My rewritten 3D box class inherits from SPGroup. Each box has six children of type Box3DSide, each of which is inherited from SPPolygon. So far so good. The problem is that I can't figure out what functions I need to call in sp_3dbox_update so that the boxes are correctly updated on screen during handle dragging (but without writing to repr for efficiency). My most promising-looking approaches so far have been:
1) Call sp_shape_set_shape() for each of the sides (where the corresponding curve is drawn). However, this does not have any visible effect during dragging (the box is shown only when sp_box3d_write() is called).
2) Call requestDisplayUpdate() for each of the sides. This is obviously wrong since it triggers an update while another one is being processed. Consequently, Inkscape issues a corresponding warning on the command line. But at least with this approach the box is correctly updated on screen.
3) Not register sp_3dbox_update() at all in sp_3dbox_class_init(). This was a last desperate attempt because I figured that perhaps the parent SPGroup would take care of udating the children. But it turned out that in this case the update methods of the sides are not even called.
So there should be something in between 1) and 2) which correctly updates the screen but doesn't issue the "update already in progress" warning. Any ideas? I'm completely lost in my maze of attempts and would appreciate any hints what else I could try or where to look further.
Thanks! Max
On Fri, 07 Dec 2007 19:32:00 +0100, Maximilian Albert <Anhalter42@...173...> wrote:
- Call requestDisplayUpdate() for each of the sides. This is obviously
wrong since it triggers an update while another one is being processed. Consequently, Inkscape issues a corresponding warning on the command line. But at least with this approach the box is correctly updated on screen.
This is basically the correct approach. The main thing is not to call it from the update handlers (you risk an infinite loop).
-mental
On Fri, 7 Dec 2007 11:27:58 -0800, MenTaLguY <mental@...3...> wrote:
On Fri, 07 Dec 2007 19:32:00 +0100, Maximilian Albert <Anhalter42@...173...> wrote:
- Call requestDisplayUpdate() for each of the sides. This is obviously
wrong since it triggers an update while another one is being processed. Consequently, Inkscape issues a corresponding warning on the command line. But at least with this approach the box is correctly updated on screen.
This is basically the correct approach. The main thing is not to call it from the update handlers (you risk an infinite loop).
(Without looking carefully at the code I can't say offhand what the appropriate place to call it from is -- potentially the knot/UI handlers.)
-mental
On Fri, 7 Dec 2007 11:27:58 -0800, MenTaLguY <mental@...3...> wrote:
On Fri, 07 Dec 2007 19:32:00 +0100, Maximilian Albert <Anhalter42@...173...> wrote:
- Call requestDisplayUpdate() for each of the sides. This is obviously
wrong since it triggers an update while another one is being processed. Consequently, Inkscape issues a corresponding warning on the command line. But at least with this approach the box is correctly updated on screen.
This is basically the correct approach. The main thing is not to call it from the update handlers (you risk an infinite loop).
(Without looking carefully at the code I can't say offhand what the appropriate place to call it from is -- potentially the knot/UI handlers.)
Thanks for this pointer! But does that mean that I can't/shouldn't update the sides from the update method of the parent group at all? Instead, I need to call the update method for each side separately from the knot handlers? This kind of "dis-encapsulation" seems a bit strange. And I still don't understand why the children are not updated automatically when the box's update method is called (after all, I thought that's what an SPGroup does with its children). Anyway, I'll give this a try and ask for further advice when I get stuck.
Thanks a bunch, Max
On Dec 7, 2007 1:32 PM, Maximilian Albert <Anhalter42@...173...> wrote:
Hi all,
I've asked this before but unfortunately I haven't been able to fix it yet. My rewritten 3D box class inherits from SPGroup. Each box has six children of type Box3DSide, each of which is inherited from SPPolygon. So far so good. The problem is that I can't figure out what functions I need to call in sp_3dbox_update so that the boxes are correctly updated on screen during handle dragging (but without writing to repr for efficiency).
Note that when you drag a node, repr is not updated but display is, for the same efficiency reason. So you can borrow it from there. The function you need is object_update in nodepath.cpp: it creates a new spcurve and manually sets it on the SPShape of the object, then issues requestModified. That's what you need to do if you want to update display while bypassing the repr update.
bulia byak schrieb:
On Dec 7, 2007 1:32 PM, Maximilian Albert <Anhalter42@...173...> wrote:
Hi all,
I've asked this before but unfortunately I haven't been able to fix it yet. My rewritten 3D box class inherits from SPGroup. Each box has six children of type Box3DSide, each of which is inherited from SPPolygon. So far so good. The problem is that I can't figure out what functions I need to call in sp_3dbox_update so that the boxes are correctly updated on screen during handle dragging (but without writing to repr for efficiency).
Note that when you drag a node, repr is not updated but display is, for the same efficiency reason. So you can borrow it from there. The function you need is object_update in nodepath.cpp: it creates a new spcurve and manually sets it on the SPShape of the object, then issues requestModified. That's what you need to do if you want to update display while bypassing the repr update.
Thanks, that's precisely what I was trying to do. I had borrowed the code from the other tools (but it's essentially the same as in nodepath.cpp) and placed it in the sides' update methods. But what drove me crazy was the fact that the curves were set alright but didn't show up on the screen - except when requestDisplayUpdate was issued, too, but since I did this from the parents' update method, it created evil cycles.
Fortunately, a first stab at MenTaL's approach of moving the calls to requestDisplayUpdate() to other places (e.g., to the knot handler functions) seems to yield promising results. I don't know why I didn't try this before, but I was so much focused on the parent-child relationship between boxes and their sides that I considered it harmful to break it to some extent by moving the displayUpdates out of the box's responsibility.
As an aside, I just noticed that you wrote "then issues requestModified" above, whereas I have only worked with requestDisplayUpdate so far (and have only seen this in the other tools' code, IIRC). Is there a notable difference between the two that could be relevant for me? Do I have to consider them both or can I stick to requestDisplayUpdate?
Thanks again, Max
On Fri, 07 Dec 2007 21:19:39 +0100, Maximilian Albert <Anhalter42@...173...> wrote:
I don't know why I didn't try this before, but I was so much focused on the parent-child relationship between boxes and their sides that I considered it harmful to break it to some extent by moving the displayUpdates out of the box's responsibility.
Again, I've not looked at the code, but that could possibly be a legitimate concern, which using modified might possibly address.
As an aside, I just noticed that you wrote "then issues requestModified" above, whereas I have only worked with requestDisplayUpdate so far (and have only seen this in the other tools' code, IIRC). Is there a notable difference between the two that could be relevant for me? Do I have to consider them both or can I stick to requestDisplayUpdate?
Modified is nice in the sense that other things which may depend on the modified shape are more likely to get updated. That may or may not be desirable for live updating, though I'd be inclined to give it a serious look since bulia has been more involved with this area of the code than I have for a long time.
-mental
participants (3)
-
bulia byak -
Maximilian Albert -
MenTaLguY