Hi, all. I wanted to give a quick update on the set of changes I committed this morning. Basically, buila's cool interruptible display code is now enhanced so that, for operations that require the whole display to be updated (rubberbanding, any sort of drawing operation), the interruptibility of the display code can be disabled and then re-enabled. During the disabled times, the entire affected screen rectangle will paint, making sure the previewed object is displayed accurately. This provides (I hope) the best balance between speed and precision while working in Inkscape.
I believe I've hit most of the drawing operations that can benefit from this change. I tested it on the last few pages of my latest webcomic, and it seems to be stable.
Thanks,
John
On 9/4/06, John Bintz <jcoswell@...1414...> wrote:
Hi, all. I wanted to give a quick update on the set of changes I committed this morning. Basically, buila's cool interruptible display code is now enhanced so that, for operations that require the whole display to be updated (rubberbanding, any sort of drawing operation), the interruptibility of the display code can be disabled and then re-enabled. During the disabled times, the entire affected screen rectangle will paint, making sure the previewed object is displayed accurately. This provides (I hope) the best balance between speed and precision while working in Inkscape.
Wait a minute. What were situations where something was NOT displayed accurately? I wasn't aware of any such cases, and if they do exist, I'd say it's preferable to fix them the right way, so that they work with interruptible display, instead of disabling interruptibility.
bulia byak wrote:
On 9/4/06, John Bintz <jcoswell@...1414...> wrote:
Hi, all. I wanted to give a quick update on the set of changes I committed this morning. Basically, buila's cool interruptible display code is now enhanced so that, for operations that require the whole display to be updated (rubberbanding, any sort of drawing operation), the interruptibility of the display code can be disabled and then re-enabled. During the disabled times, the entire affected screen rectangle will paint, making sure the previewed object is displayed accurately. This provides (I hope) the best balance between speed and precision while working in Inkscape.
Wait a minute. What were situations where something was NOT displayed accurately? I wasn't aware of any such cases, and if they do exist, I'd say it's preferable to fix them the right way, so that they work with interruptible display, instead of disabling interruptibility.
In situations where the redraw is very complicated, especially if the zoom factor is high (~1000-2000%) and if working with a tablet, the drawing of the dragged or new item on the screen can take longer than the processing of the events for this item. When drawing, say, a rectangle from top to bottom in one of these complicated areas, the preview item may not be finished drawing by the time the new event is received. This new event will cause the display to start updating again, ending the previous update and preventing the user from seeing a completed rectangle. I ran across this many times while working on some very calligraphy-path heavy drawings recently -- nodes and handles would not update completely, leaving me to guess as to how a drag operation would leave my finished drawing. Also, rectangles and arcs wouldn't draw at all sometimes, because the redraws were being interrupted with almost every mouse movement.
If you like, I can create a test document to send to you so that you can see the behavior for yourself. I personally would want to see a better method for handling this case, as well. What I think might be ideal is to flag particular objects as "must draw completely," objects such as ones that users are working on that have not been committed to the document. Again, this only occurs during times when screen redraws will take a long time (and with some of the documents I work on, they can be very slow due to the large number of paths and the zoom levels I work at).
John
On 9/5/06, John Bintz <jcoswell@...1414...> wrote:
In situations where the redraw is very complicated, especially if the zoom factor is high (~1000-2000%) and if working with a tablet, the drawing of the dragged or new item on the screen can take longer than the processing of the events for this item. When drawing, say, a rectangle from top to bottom in one of these complicated areas, the preview item may not be finished drawing by the time the new event is received. This new event will cause the display to start updating again, ending the previous update and preventing the user from seeing a completed rectangle. I ran across this many times while working on some very calligraphy-path heavy drawings recently -- nodes and handles would not update completely, leaving me to guess as to how a drag operation would leave my finished drawing. Also, rectangles and arcs wouldn't draw at all sometimes, because the redraws were being interrupted with almost every mouse movement.
This sounds reasonable, but your change seems to remove any interruptibility at all, e.g. while dragging a rubberband. Is that so?
Without interruptibility, while each rubberband rect is redrawn fully, it may take quite a long time for it to complete. So while you will see the entire rect, it will lag behind the mouse.
By contrast, with interruptibility, you may see only the top strip of the rubberband rectangle, but it is much more responsive and tracks the mouse more closely. Besides, in my testing, it is never so bad as to never completely redraw; when I move the pen fast (I use a Graphire tablet with pen), I see the top strip only, but as soon as I slow it down, it "gets through" and starts doing complete or almost complete redraws. So I never perceived this as a problem, and indeed considered it to be an advantage.
Similarly, when I drag a big and complex object, previously (without interruptibility) it was very frustrating: each redraw was complete and took a lot of time, and therefore the redraws were lagging behing the mouse quite a lot. Now, with interruptibility, when I move the pen fast, it looks like I'm dragging only the top strip of the object, and it is therefore much more responsive. I can watch this top strip to position the object much more interactively than before, and as soon as I slow down or stop my movement, it completes the redraw in the new position. So, again, to me this is an advantage, not a problem.
If however for you this is a problem, let's find a compromise. I think a better approach would be to force _some_ of the redraws to be complete and let others be interrupted. For example, after every 5 interrupted redraws insert one forced complete one. I think this will be the best approach overall. What do you think?
bulia byak wrote:
Similarly, when I drag a big and complex object, previously (without interruptibility) it was very frustrating: each redraw was complete and took a lot of time, and therefore the redraws were lagging behing the mouse quite a lot. Now, with interruptibility, when I move the pen fast, it looks like I'm dragging only the top strip of the object, and it is therefore much more responsive. I can watch this top strip to position the object much more interactively than before, and as soon as I slow down or stop my movement, it completes the redraw in the new position. So, again, to me this is an advantage, not a problem.
The most noticeable (and frustrating) delays for me were in node handle manipulations. I've been adjusting my tablet settings (Intuos2 on Ubuntu dapper) to reduce the number of motion events sent from the driver, but regardless of the settings, I'm still flooding Inkscape with events. The biggest offender involved text balloons in my comics, which often required manipulating nodes around the text while zoomed in pretty far. Sometimes these nodes were not at the tops of the redraw sections, and in those cases, I never saw an update until I was done dragging and I let go of the handle.
If however for you this is a problem, let's find a compromise. I think a better approach would be to force _some_ of the redraws to be complete and let others be interrupted. For example, after every 5 interrupted redraws insert one forced complete one. I think this will be the best approach overall. What do you think?
I think that would be a good approach. Would you envision this being enabled/disabled on a per-tool/per-event basis or as something more global to be handled exclusively by SPCanvas?
John
On 9/5/06, John Bintz <jcoswell@...1414...> wrote:
The most noticeable (and frustrating) delays for me were in node handle manipulations.
I agree - for node editing interruptibility is rarely useful, simply because it redraws the entire path, and most often the segment you're editing is not in the top strip, which means it gets redrawn very unfrequently. Indeed, in this situation forced redraws should help.
a better approach would be to force _some_ of the redraws to be complete and let others be interrupted. For example, after every 5 interrupted redraws insert one forced complete one. I think this will be the best approach overall. What do you think?
I think that would be a good approach. Would you envision this being enabled/disabled on a per-tool/per-event basis or as something more global to be handled exclusively by SPCanvas?
I think we can use an API similar to what you already added:
sp_canvas_force_full_redraw_after_interruptions (canvas, 5)
where the numeric parameter is the number of _consequential_ _interrupted_ (not just interruptible) redraws after which a complete redraw is forced. Can you please code this?
Then, I'd propose that we start using this call in node tool, trying to find the best value of the numeric parameter. If this works out, we may look into adding it in other places too, where needed. However I'm against adding it indiscriminately in each place where we process motion events.
bulia byak wrote:
I think we can use an API similar to what you already added:
sp_canvas_force_full_redraw_after_interruptions (canvas, 5)
where the numeric parameter is the number of _consequential_ _interrupted_ (not just interruptible) redraws after which a complete redraw is forced. Can you please code this?
Then, I'd propose that we start using this call in node tool, trying to find the best value of the numeric parameter. If this works out, we may look into adding it in other places too, where needed. However I'm against adding it indiscriminately in each place where we process motion events.
I just committed the code changes for these. The new forced redraw code is written as you asked, and it's only enabled and disabled in the node and node handle dragging/release code in nodepath.cpp. The other tools have been set back to how they were. My initial testing shows that node manipulation is more responsive on some of my more complicated documents after these changes. What is your experience?
John
participants (2)
-
bulia byak -
John Bintz