Hi Mike, thanks for the detailed information. > 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. There is also gdk_gl_config_get_visual() and gtk_widget_set_visual(), which would allow to apply the GdkGLConfig's visual to the GtkGLWidget. Could this be used for setting the widget's visual? According to GTK's API documentation, gtk_widget_set_visual() must be called before the widget has been realized, but it should allow to keep both components separated. > 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. From the perspective of an application developer, I think GdkGLExt should follow the same approach as GDK 3. The display can be obtained directly from GDK, and it does not change at run time (e.g., move the window from X11 to a frame buffer, etc.), right? From reading the porting guide you referenced, it doesn't sound too complicated. Best regards Thomas -- GnuPG: http://tdz.users.sourceforge.net/tdz.asc Fingerprint: 16FF F599 82F8 E5AA 18C6 5220 D9DA D7D4 4EF1 DF08 jsapigen - A free glue-code generator for Mozilla SpiderMonkey. See http://jsapigen.sourceforge.net for more information.
Attachment:
signature.asc
Description: This is a digitally signed message part