Hi, any news on the state of this? Regards Thomas Am Freitag, den 02.12.2011, 23:43 -0500 schrieb Mike Paul: > 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 -- 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