Re: [GtkGLExt] Working on GTK 3 support; feedback requested

[Mike Paul <mike wyzardry net>]

On Mon, 2011-11-28 at 18:42 +0100, Thomas Zimmermann wrote:
> I'm currently looking for ways to write an OpenGL application on top of
> GTK+ 3. Porting gtkglext looks like the most promising option, and I'm
> willing to help you with that. Can I find your patches somewhere?

Not yet; all I've really done so far is bump the version number to 2.0
(actually 1.99) and make GdkGLWindow and GdkGLPixmap derive from GObject
instead of GdkDrawable.  Beyond that it's just exploratory, nothing
ready for use yet.  I expect to publish my Git branch once I have some
more confidence that I'm "on the right track" -- I wouldn't want to
publish a bunch of changes and then ask people to discard them because
they were a bad design.

What I hope to do is keep building against GTK 2 while refactoring to
remove use of deprecated stuff that doesn't exist in GTK 3, and *then*
change to building against GTK 3, which should hopefully be a relatively
small change at that point.  That keeps the codebase always in a working
state, but it requires more planning than the alternative, changing the
makefiles to link against GTK 3 first and then fixing all the errors.

> Regarding the issues with GdkGLPixmap, why not simply let it maintain
> its own internal X Pixmap? A GdkGLPixmap would be created with a call
> like
> 
>   GdkGLPixmap* gdk_gl_pixmap_new(gint width,
>                                  gint height,
>                                  const int *attrib_list)
> 
> The X Pixmap would be queried via
> 
>   Pixmap gdk_x11_gl_pixmap_get_pixmap(GdkGLPixmap *gdkpixmap)
> 
> Supplying the returned X Pixmap to cairo_xlib_surface_create_for_bitmap
> would give the user a cairo context to draw to.

The problem with that approach is that it sacrifices the
platform-independence that GDK provides; applications would have to
directly call Xlib or Win32 functions and link against the
platform-specific libraries that provide them.  I think it'd be good for
GtkGLExt to provide an "escape hatch" for working with platform-specific
stuff if *necessary*, but it shouldn't be *required*.

> OTOH, everyone using off-screen drawables has probably switched to FBOs,
> so dropping pixmap support entirely for now might not be that much of a
> problem.

That's a good point, and I'm tempted to do that; they can always be
added back later (in a suitable form) if necessary.  I'm reluctant to
assume that nobody really needs GL pixmap support, though; feedback from
additional developers would be valuable.
-- 
Mike Paul <mike wyzardry net>