1:47 a.m.
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
10:14 p.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
12:31 a.m.
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
1:53 a.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
2:17 a.m.
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
2:42 a.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
12:38 p.m.
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
6230
days inactive
6231
days old
inkscape-devel@lists.inkscape.org
6 comments
2 participants
participants (2)
-
bulia byak -
John Bintz