Hi Mike!
> Regarding gtk_widget_set_visual(), btw, the problem isn't with setting
> the visual used by the GtkGLWidget. The problem is that when a
> GtkGLWidget is added to a GtkWindow -- a top-level window with a
> titlebar, etc. -- GtkGLExt needs to take the GL widget's colormap and
> set it as the whole window's colormap, otherwise the X server might not
> notice that it needs to use a special colormap for something in that
> window. And a visual doesn't represent a specific colormap, so the
> visual get/set functions can't do that.
I had a look at the source code of GtkGLWidget and into the Xlib
Programming Manual. Normally, the WM_COLORMAP_WINDOW property says which
child windows need a special colormap for drawing. Installing the GLX
window's colormap onto the top-level X window seems to fix rendering
with window managers that ignore the property. So, this code is a
workaround for some window managers that ignore the WM_COLORMAP_WINDOWS
property of the top-level X window.
> However, I took a look at the existing code to find out what role the
> GtkGLWidget's visual actually plays, and the result is that I'm a bit
> confused. The way I *think* it's supposed to work is:
>
> * You call glXChooseVisual() to find the "best" (for GL purposes)
> visual that your display supports.
> * Then you create an X11 window using XCreateWindow(), which takes
> the visual as one of its arguments.
> * Finally you call glXCreateWindow() to create a GLX window based
> on the X11 window. The X11 window and the GLX window are two
> distinct things even though they represent the same area of the
> screen.
> * To draw, you pass the GLX window to glXMakeCurrent().
>
> But GtkGLExt doesn't ever call glXCreateWindow() as far as I can see.
> Instead, it treats the X11 window as if it were a GLX window:
> gdk_gl_window_new(), in gdkglwindow-x11.c, calls GDK_WINDOW_XID() on a
> GtkWindow and stores the resulting ID into a variable that later gets
> passed to glXMakeCurrent(). I'm not sure whether that's a correct and
> portable thing to do, or if it's technically wrong but happens to work
> with common GLX implementations.
This behavior is actually correct. The code you mention is written for
GLX 1.2. Passing the X window to glXMakeCurrent is allowed here. Citing
the GLX 1.4 spec [1], pg. 3:
'For backwards compatibility with GLX versions 1.2 and earlier, a
rendering context can also be used to render into a Window. Thus, a
GLXDrawable is the union {GLXWindow, GLXPixmap, GLXPbuffer, Window}.'
The function glXCreateWindow appeared in GLX 1.3, which btw deprecated
most of the old interface.
> GtkGLExt does call glXChooseVisual(), in gdk_gl_config_new_common() in
> gdkglconfig-x11.c, but it looks like the resulting visual is only used
> for choosing a suitable colormap. GDK makes its own decision about what
> visual to use when it actually creates a window. Typically they'll both
> choose a TrueColor visual anyway, but there could be problems if GDK is
> configured to use indexed color for some reason: it'd end up trying to
> apply an RGB colormap to an indexed window.
Hmm, don't know... I guess it is up to the application programmer to
correctly specify RGBA or indexed mode when creating the GdkGLConfig for
the GL window.
Best regards
Thomas
[1] http://www.opengl.org/documentation/specs/glx/glx1.4.pdf
--
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