Since this'll take some more research before significant progress can be made, I thought I'd share a few additional porting issues I've identified. I'm learning about this stuff as I go along, so any insights from people with more experience than me would be welcomed.
The first issue is colormap handling. GdkColormap no longer exists in GDK3, but we have gdk_gl_config_get_colormap() that returns one, and it's used in the implementation of GtkGlWidget to install the GL widget's colormap into the top-level window that contains it. (Indexed color support isn't very interesting these days, especially for OpenGL, but if it works currently, I'd prefer not to break it.) According to the GTK3 porting guidelines: "For drawing with cairo, it is not necessary to allocate colors, and a GdkVisual provides enough information for cairo to handle colors in 'native' surfaces. Therefore, GdkColormap and related functions have been removed in GTK+ 3, and visuals are used instead." I'm thinking I'll remove gdk_gl_config_get_colormap() from the API and push GtkGLWidget's colormap installation needs down into the platform-specific backend code that can work with raw X11/Win32/etc. colormaps. That should work, but it may be a little klugey. Cairo presumably has to deal with this too, when a cairo surface is placed into a toplevel window on an indexed-color display, so I'd like to find out how it's implemented there; it may be informative. The other issue relates to GTK backends. On my Debian system, the GTK 2 library is named "libgtk-x11-2.0.so.0", and on a Windows system it's "libgtk-win32-2.0-0.dll". But GTK 3 is simply "libgtk-3.so.0" and "libgtk-3-0.dll" -- the backend isn't part of the filename. According to [1], that's because it can be built with support for multiple backends in the same library. I'm wondering whether GtkGLExt ought to follow the same strategy. If the system's installed GTK and GDK libraries are built with both Xlib and XCB support (for example), an application can presumably be run using either backend, without recompiling it. But if GtkGLExt continues to build separate libraries for each backend (e.g. "libgtkglext-x11-2.0.so.0" and "libgtkglext-xcb-2.0.so.0"), the application can only link against one of them, so it'll fail if it's run using the "wrong" kind of connection to the X server. This isn't an immediate concern since there doesn't seem to be a released XCB backend for GTK (though I didn't spend much time looking), nor a widely-accepted port of the GLX API to XCB. But if we make the change later, it breaks ABI so existing apps have to be recompiled. Right now, there are no existing apps linked against GtkGLExt 2, so it's the ideal time to do it, if it's really the right thing to do. That's all I have for now. I think I'll focus on studying the colormap issue, since getting it resolved will be a definite step forward and it may turn out to be relatively simple if cairo provides a good example to follow. [1]: http://developer.gnome.org/gtk3/stable/ch25s02.html#id1400118 -- Mike Paul <[email protected]> _______________________________________________ gtkglext-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkglext-list
