On 23 August 2013 00:35, Jon Nordby <jono...@gmail.com> wrote: > > > On 17 August 2013 21:45, Andrew Chadwick <a.t.chadw...@gmail.com> wrote: >> >> 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. > > > Hi, > sorry that I did not respond until now, after it has been merged. Also saw > that a lot of GUI work went in, cool! > > "Pupuser" on #mypaint said that master appears much slower than 7e27a690 on > his machine. > David Revoy also noted some apparent slowness in rendering with master. I > have not tested much yet, both said they would follow up with more detailed > info later.
Seems that noone did this. However, popolon just recorded a video demonstrating the problem: http://popolon.org/cubieboard/mypaint.git.vs.mypaint.jonnorified.ogv The performance regression is quite serious, and likely affects everyone who runs the application. I don't think this is an acceptable side-effect of a workaround for a GTK+3 bug, which only helps somewhat and only for the people with GTK+ 3.8.x+ - and should really be fixed there. Any feedback on the comments below? > >> 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. > > > In this bug it is mentioned that GTK 3 (also pre-3.8 regression) event > delivery is slower than GTK 2, but I do not see any data for that case. How > much slower are we talking? Isn't that the real source of bug 20822? > > And with GTK 3.8+, are you actually seeing improvements in event rate with > this new code? > Because, if I understood the GTK guys correctly, only one motion event will > be delivered per _redraw_, and this only makes motion_to faster... > In fact, if we do not cause a queue_redraw event directly from the motion_to > handler anymore - the redraw rate seems to be more likely to go down to me? > > So I guess what I am asking is, why the need for queuing to add > interpolation of events? What is the disadvantage of just doing it directly > in the handler? > > > If reducing the work done in the motion_to handler is important, here is how > I propose doing it: > * Make mypaint_tiled_surface_end_atomic() just return the bounding box, > and not actually do any work to realize the operations on the tiles. > * Introduce a new function, mypaint_tiled_surface_process_region() which > takes a bounding box and executes the pending computations on the > appropriate tiles. > For large bounding boxes it should do its work in chunks, trying to never > exceed more than XX milliseconds in one go. It should return the bounding > box of the actually processed subregion and a value indicating whether it is > done or has more to process. > * Calling this processing function would probably be a responsibility of > lib.document.Document. It could happen directly as part of the redraw > callback, behind render_into(). > Or, an idle function could processed the queued invalidations on surfaces > (from end_atomic()) as fast as it can and then notify of document as they > are completed to trigger queue_redraws on TiledDrawWidget. This would help > avoid blocking the GUI thread when brush engine is overloaded. -- Jon Nordby - www.jonnor.com _______________________________________________ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
