I'm trying to address https://bugzilla.gnome.org/show_bug.cgi?id=702392 https://gna.org/bugs/?21003 https://gna.org/bugs/?20822
as much as we can in MyPaint by tweaking the way that we deal with stroke processing. We really need an upstream fix for this problem, but in the meantime there's stuff we can do to make the experience nicer for users of the new Gdk. Current work on it can be found at https://gitorious.org/mypaint/mypaint/commits/gtk3-stroke-queue and testing would be most welcome. I'm currently developing against Debian testing's Gtk 3.8.2, which appears unaffected by this upcoming 3.8.x regression for now. However, I can test with the kit at my disposal and try and get the input side of things right for when this does hit mainstream Linux distros. See Gna! bug 21003 for some measurements. For me, ameliorating the upcoming problem is equivalent to ameliorating the angular stroking when scribbling spirals with that touchpad. As the name implies, this approach relies on queueing input strokes. Specifically: * All the input handler does is queue the raw event values from each event we receive, and then returns. The goal here is to sample as fast as we can with Python code; before we'd render all incoming data from the event before returning, which may worsen the problem posed by upstream breaking event delivery at the rate at which events occur. * The handler for the raw input data interpolates linearly between events at the delivered ~50Hz to generate stroke position/pressure/tilt data at ~400Hz. It then queues this for consumption by Layer.stroke_to() and all points beyond. This generates greater apparent smoothness in the processed brush strokes, though the effect is discernible at a faked ~200Hz. The smoothing effect is of course only actually apparent with a small setting in Slow Position Tracking. -- Andrew Chadwick _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
