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 <[email protected]> _______________________________________________ gtkglext-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkglext-list
