Re: [GtkGLExt] GTK3: additional considerations



On Tue, 2012-01-03 at 19:36 +0100, Thomas Zimmermann wrote:
> Hi,
> 
> any news on the state of this?

Sorry, I didn't spend much time on GtkGLExt in December -- sidetracked
by holiday stuff and an introductory foray into Android programming.  I
hope to spend more time on it in January.

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.

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.

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.
-- 
Mike Paul <mike wyzardry net>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]