[GtkGLExt] Working on GTK 3 support; feedback requested

[Mike Paul <mike wyzardry net>]

Recently I've been looking into the technical details of porting
GtkGLExt to GTK 3.  I'd like to share what I've found and solicit some
feedback on the API changes involved.

So far, I've been looking only at the GdkGL stuff, not the higher-level
GtkGL stuff.  The big change between GDK 2 and 3 is that GDK drawing is
completely gone, superseded by cairo.  That means the GdkDrawable and
GdkPixmap classes no longer exist, both of which are currently used by
GdkGL.

Removing references to GdkDrawable turns out to be fairly
straightforward; I've already done most of that.  But the lack of
GdkPixmap poses a bigger challenge, because GdkGLPixmap depends on it
heavily.  Since cairo is the designated successor to GDK's drawing
facilities, it seems to me that GdkGLPixmap should now draw into cairo
surfaces.

One way to accomplish that is to just change gdk_gl_pixmap_new() so it
takes a cairo_surface_t* argument instead of a GdkPixmap* one.  That's
pretty straightforward, but it results in an inconsistent API:
applications have to utilize a GDK type (GdkWindow) to render into an
onscreen window, but they have to bypass GDK and create a cairo surface
manually to render into an offscreen buffer.

Alternatively, GdkWindow itself supports offscreen windows, which
basically just wrap GdkPixmaps on GDK 2, and cairo surfaces on GDK 3.
It might make sense to remove GdkGLPixmap entirely, and instead make
GdkGLWindow support both onscreen and offscreen GdkWindows.  It's a
bigger API change, but any application using GdkGLPixmap is probably
using GdkPixmap too, so it already has to cope with significant API
changes anyway.  Doing it this way would avoid the inconsistency
mentioned above, and GDK would take care of creating the cairo surface
for offscreen drawing.

Either way, we end up with a cairo_surface_t that we want to draw into
with OpenGL.  The implementation will need to check that the given
surface is of a suitable type, e.g. CAIRO_SURFACE_TYPE_XLIB on X11 and
CAIRO_SURFACE_TYPE_WIN32 on Win32, to make sure the caller didn't pass
something weird like a PDF surface.  (This is probably more of a concern
if the application is responsible for creating the surface directly,
rather than letting GdkWindow do it.)  Once the type of the surface is
known, cairo provides functions for extracting the underlying native
window handle, which can then be used with OpenGL.

If anyone on the list has any insights into which of these alternatives
would be preferable, or into GTK 2/3 porting in general, any feedback
would be appreciated.  In the meantime, I plan to experiment with GDK's
the offscreen windows, to make sure they work the way I think they
should from the documentation.
-- 
Mike Paul <mike wyzardry net>