Hi all,
I don't know anything about how GTK3 works, but I would be inclined to
agree with the responses Daniel got on that mailing list: lack of
smoothness of the shapes means that the *events* are not sufficiently
fine-grained.
Excessive rendering slowness would cause a perfectly nice shape to be
drawn well behind the position of the pen, with a very noticeable lag
but no loss of smoothness (as is already the case if you try to draw
very fast in xournal when e.g. you're working over a remote X11
connection and/or the CPU kept 100% occupied by other processes (try
e.g. running ssh -X machine from one system to another one, not on the
same fast local network, and running xournal within the ssh -- possibly
further overloading the network and/or CPU with other stuff going on --
and you'll see what I mean).
The description I found of gdk_window_set_event_compression() sounds
exactly like what would cause polygonal lines to appear instead of round
circles -- this seems to be a new feature in gtk3. I have never
benchmarked carefully but I do imagine that xournal typically receives a
number of motion events (and creates the corresponding line segments and
asks gnomecanvas to draw them, which I assume is NOT done synchronously
-- in any case gnomecanvas does not actually push the display surface to
the screen each time) in sequence before any display refresh actually
takes place, and during the time when the display gets refreshed the
motion events get queued and will be processed once the display refresh
is done. The GTK3 event compression would eliminate all intermediate
motion events that occurred during the display refresh and just give you
a single position, losing all the intermediate ones; turning it off
should help a lot.
Actually, this is exactly what it says here:
========
void gdk_window_set_event_compression (GdkWindow *window,
gboolean event_compression);
Determines whether or not extra unprocessed motion events in the event
queue can be discarded. If TRUE only the most recent event will be
delivered.
Some types of applications, e.g. paint programs, need to see all motion
events and will benefit from turning off event compression.
By default, event compression is enabled.
========
We are a paint program and need to see all motion events :)
I'm having a horrible two weeks at work and will acquire a new child in
about a month, so this is not the right time for to engage in any
serious xournal-related work, but my suggestion would be to see if just
disabling event compression helps with stroke smoothness. If it fixes
smoothness but causes display lag issues, then you can go back and
complain about the rendering performance again :-)
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
