Notes on wip/gdk-gl2

[Owen Taylor <otaylor redhat com>]

I spent a bit of time looking at the wip/gdk-gl2 branch. In general, the
public API looks very good to me - minimal but sufficient. I think the
branch is basically good to land.

Performance on my system is actually quite poor in at the moment, which
seems at least to be pathological interactions with the system
(i915, Fedora 21, Haswell.) I see 60fps with the default configuration
of gdkgears for any windowed size of the window, but when I maximize I
see the frame rate drop to 30fps, and when I make it fullscreen, I see
it drop to 10fps. 'perf top' shows kernel memory allocation as the top
functions, so it may be that the continual allocation of new render
buffers is triggering the problem.

I also see rendering locked at a sub-multiples of 60fps - despite the
fact that the rendering is additionally synchronized with the compositor
frame clock. If I export vblank_mode=0 I see the expected non-locking
behavior.

* Docs for gdk_cairo_draw_from_gl() need to describe where the rendering
ends up (0, 0 of the curent user coordinates, it seems)

* Docs for gdk_cairo_draw_from_gl should document that it disturbs the
current GL context.

* It looks like there's a need to create a GdkGLContext for a window
*before* the paint callback it is first used, since we use the existence
of the internal paint GL context to know whether we are using GL for
this paint; this is not documented.

* Does the paint GL context need to be always derived from the toplevel
or nearest native ancestor of a GdkWindow? It looks to me like things
might not work right if gdk_window_create_gl_context() is called on a
client side subwindow.

* GtkGLArea tries to keep the context on unrealize() unless the screen
changes; but this doesn't seem workable - first because of the need
of the context to be created sharing with the internal paint context in
GDK, and second because realize() doesn't actually check if the context
already exists.

* The approach of continually creating the render buffer may not give
good enough performance, but if we do that, it's definitely desirable to
create a minimal sized render buffer instead of one that's the size of
the widget, since the cost of allocating a buffer gets larger the more
pages that have to be allocated.

* What's the intended event handling for GtkGLArea? It seems like you'd
have to put it into a GtkEventBox and handle events on the GtkEventBox -
maybe GtkGLArea should have an event window?

* The name gdk_gl_context_flush_buffer() is confusing to me -
end_frame() might be better.