Re: GTK+2 vs. GTK+3 signal “expose/draw/render” events

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 3 October 2016 at 21:54, Sébastien Le Roux
<sebastien leroux ipcms unistra fr> wrote:

> Hello everyone and thanks for reading this,
> You will find the same message posted on stackoverflow by following this
> link
> <http://stackoverflow.com/questions/39837159/gtk2-vs-gtk3-signal-expose-draw-render-events>
> (or pretty much the same),
> but I figured that the gtk mailing list was probably a better way to get the
> help I need.
> My name is Sébastien Le Roux, I am working on a program that offers a
> visualization interface for molecules,
> atomic systems ... I have 3 different versions of my program:
>
>  * (a) GTK2 + GtkGlext : works great !
>  * (b) GTK3 + X11 : works just fine !
>  * (c) GTK3 + GtkGLArea : does not work :-(

By "GtkGLArea" I assume you mean the GtkGLArea widget that GTK+
provides since 3.16:

  https://developer.gnome.org/gtk3/stable/GtkGLArea.html

But you'll have to define "does not work".

I also have no idea how you're using OpenGL on GTK+ without GtkGLArea
— I assume you're just creating a custom widget with a GdkWindow
backed by a native X11 surface, and then just creating a GLX context
with that. That's not really supported, and it only happens to work
because projects like Clutter still use this approach and we cannot
really change them.

> While I am still working on (c), I learned that the GtkGLArea is rather
> picky concerning the OpenGL commands,

GtkGLArea is not "picky": as the documentation says, GtkGLArea
supports OpenGL 3.2+ core profile contexts by default, and only falls
back to OpenGL compatibility profiles if the GL stack does not support
GL versions ≥ 3.2 (starting from GTK+ 3.20).

> some things came up while I was trying
> to find out the origin of some behavior differences between (a) and (b). The
> OpenGL rendering is significantly slower in (b) than in (a), or I thought
> that was the case.

How do you measure "slowness"?

> If you check this link
> <http://stackoverflow.com/questions/39789414/how-to-get-as-many-information-as-possible-about-an-opengl-context>
> you will see that I got some help and manage to find out that GTK+ signals
> were not handled in the same way between GTK+2 (a) and GTK+3 (b), and (c)

Yes, they most definitely do not match because GdkGLContext and
GtkGLArea use the GTK+ drawing cycle instead of just rendering to a
native surface that may or may not end up on the screen. This allows
GtkGLArea to have popovers that blend with the contents below, or
semi-transparent widgets on top of the GL content, unlike the "native
rendering" approach, which does not allow either.

> Using the tool Apitrace I noticed in case (a) that each OpenGL frame was
> drawn once, while it was drawn 5 times in cases (b) and (c). Then just
> adding a basic counter in the callback I confirmed that for each
> "expose/draw/render" the signal was emitted (and thus the "drawing-area" was
> rendered that many times, for the same frame):

You're comparing two fundamentally different toolkits — GTK+ 2.x and
GTK+ 3.x. The rendering process has been completely changed since the
2.x days, so it's literally pointless to draw a comparison. You're
also trying to compare rendering done out of order, on a separate
windowing system surface, with an integrated rendering pipeline that
includes OpenGL.

In general, GTK+ only draws what needs to be drawn, including specific
regions. This may lead to multiple calls to ::draw(), or, in case of
GtkGLArea, multiple calls to ::render(), though multiple invalidations
are generally coalesced together.

You can get a quick overview of how GTK+ draws from this blog post:

  https://blog.gtk.org/2016/06/15/drawing-in-gtk/

> (a) is GTK+2, (b) and (c) are GTK+3 ... now my question will be rather
> obvious, but how can I changed or maybe should I say correct the GTK+3
> version of my program to make it as smooth, on an OpenGL rendering point of
> view, as the GTK+2 version ?

It's likely you're rendering too much yourself; for instance, you may
be constantly queueing redraws in the middle of a render(), by
changing widget states; or, worse, you could be queueing a whole
relayout during rendering.

Without knowing what you're doing inside your code, there's not enough
context to give you a sensible answer.

Ciao,
 Emmanuele.

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