freehand mode: improve scribble responsiveness
authorAndrew Chadwick <andrewc-git@piffle.org>
Sun, 4 Aug 2013 22:30:27 +0000 (23:30 +0100)
committerAndrew Chadwick <andrewc-git@piffle.org>
Tue, 20 Aug 2013 19:20:02 +0000 (20:20 +0100)
commit7127efd94ceff8868fbba1cd09ac30e30ef100b1
tree688285022a38482cf2499264ab68c499e87d7896
parent7e27a6905a9baf7f5509e26187f8d2c350f0d092
freehand mode: improve scribble responsiveness

Improve responsiveness and the effectiveness of Slow Tracking under GTK3 by
processing input events with as fast a turnaround as possible, and
deferring both motion data cleanup and stroke rendering via a pair of
queues. Adds a degree of linear interpolation, primarily to make smaller
chunks of work for the backend renderer, allowing it to return quicker and
stop lagging the CPU cores (one of which will be handing input events at
the same time).

This helps address the problem since GTK3 was turned on by default in
commit 90b3ade2 whereby very, very fast scribble strokes would turn into a
series of line segments rather than nice smooth curves, even with Slow
Tracking. The speed with which GTK3 delivers input events seems to be very
much more bound by concurrent CPU use than with GTK2 for reasons which have
me guessing.

Brush authors will need to introduce a small amount of Slow Tracking (not
Slow Tracking Per Dab) to allow this fix to take effect for their
super-fast scribbly brushes: existing ones with Slow Tracking in the 0.5 to
1.0 range seem to do OK on my system at least, so try that.

Major user benefit of these per-mode-instance queues: strokes which are
slow to render are now seen to be "working slowly" in the UI, and can be
cancelled during the render/display crawl by pressing Escape. Better than
staring a blank unresponsive screen, anyway.

Fairly hefty potential drawback: greater total overhead. The finer chunks
mean a reduced capacity for MP stuff. Perhaps some messing with
begin_atomic/end_atomic and when they're called might work (more
stroke queues...)
gui/canvasevent.py