Re: gtk_widget_queue_draw_area much slower in gtk3 than gtk3

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 30 March 2015 at 06:16, dmg <dmg uvic ca> wrote:

> I am one of the developers of xournal. We have been trying very hard
> to port from gtk2 to gtk3 (specially since gnomecanvas was abandoned).
> I recently joined xournalpp which is a new rewrite of xournal, and it
> is in the same boat:
> trying to go from gtk2 to gtk3.
>
> So far the functionality is there, but we have been hit by a major
> problem in both apps: gtk3 is much slower rendering to the canvas than
> gtk2.

I'm very sceptical about this conclusion…

> I have tried to track this problem down, and my experiments suggest
> that it is the call to
>
> gtk_widget_queue_draw_area
>
> We draw a segment of a line  using cairo, but it does not get drawn
> to the screen until gtk_widget_queue_draw_area is called. Which is
> fine. But under gtk3
> it really slows down sampling of the stylus.

… Because you're talking about events.

Motion events are compressed in GTK+; they get collected and pushed to
the application code once per frame, because you cannot obviously
paint any faster than what your display can show, and because the vast
majority of applications do not draw content in response to fine event
delivery.

You have two options:

 * use the event history for the devices you're interested in
 * disable motion event compression on the GdkWindow that you're using
to detect events, and build up the positions you will then draw

Other painting applications opted for the latter solution, so you
should likely explore it first; see the API reference:

  https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-set-event-compression

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[ ] ebassi [ gmail com]