Further thought: if disabling event compression makes drawing work well and smoothly, but things like scrolling or moving a selection across the page become too slow, then we want to be smarter -- e.g. re-enable compression when we enter start_movesel() or start processing a scrolling event, or the hand tool, or vertical space etc. -- and disable it again when we're done and might actually be drawing. (This may be easier said than done, because I think the event wiring on the scrollbars is pretty much done by gtk, so I'm not sure where we can catch things -- on_vscroll_changed might be too late.)
(Perhaps actually we want to keep compression on most of the time, but disable it when we call create_new_stroke(), do_eraser(), or start_selectregion() in on_canvas_button_press_event() in xo-callbacks.c; and re-enable it when we call finalize_stroke(), finalize_erasure(), or finalize_selectregion()). Of course, if the scrolling handlers etc. are up to par in terms of performance then we can probably just keep compression disabled the whole time. But in principle, scrolling or moving a selection is potentially more intensive than drawing with the pen, because it affects a larger part of the display at the same time, and during those operations we don't actually need to keep track of the intermediate positions of the pen and respond to each of them, it's okay to discard intermediate ones! Best, Denis On 03/30/2015 01:09 PM, D M German wrote: > Bernhard Reiter twisted the bytes to say: > > > Bernhard> I've found a thread which seems to indicate that Daniel found the > reason > Bernhard> for the performance issues and might've resolved them afterwards > [1] -- > Bernhard> hence my questions if it might be time to start an "official" gtk3 > Bernhard> branch and release an alpha into the wild for further testing. > After > Bernhard> all, Daniel's work now almost 1.5 years old -- would be too bad > to just > Bernhard> leave it lying around. > > Bernhard> (CC'ing Daniel) > > it is actually more complicated than that. > > I started looking at the gtk3 branch of xournalpp (it is now in working > condition) and it suffers the exact same problem than my code using > goocanvas. What is special is that xournalpp does not use any > library. it implements rendering directly. > > So I started digging and so far I think this is the most promising lead: > > See this and the responses: > > https://mail.gnome.org/archives/gtk-app-devel-list/2015-March/msg00074.html > > I am still following up with it. Denis, you are a much better expert at > the event handling than I am, so your feedback might be valuable. > > -dmg > > > Bernhard> Bernhard > > Bernhard> [1] > Bernhard> > https://mail.gnome.org/archives/goocanvas-list/2013-November/msg00007.html > > Bernhard> On 2015-03-27 18:14, Denis Auroux wrote: > >> As far as I understand, there are still performance issues on larger > >> documents, caused by the gtk3 canvas libraries being much less efficient > >> than libgnomecanvas. Or have they been fixed? (I haven't followed > closely). > >> > >> -- Denis > >> > >> On 03/27/2015 01:12 PM, Bernhard Reiter wrote: > >>> Hi, > >>> > >>> I've tried out Daniel German's Gtk3 port [1] of xournal, and found it to > >>> work quite well -- everything that I normally use xournal for seemed to > >>> work. I was curious if there were plans to merge his branch into the > >>> official repo any time soon and/or maybe release an alpha version for > >>> public testing, as the port has been around for a while. > >>> > >>> Regards > >>> Bernhard > > > -- > Daniel M. German "The greatest dangers to liberty > lurk in insidious encroachment > by men of zeal, > well-meaning > Louis Brandeis -> but without understanding." > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > > > -- Denis Auroux UC Berkeley, Department of Mathematics 817 Evans Hall, Berkeley CA 94720-3840, USA aur...@math.berkeley.edu ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
