Re: [GtkGLExt] GTK3: additional considerations
- From: Mike Paul <mike wyzardry net>
- To: tdz users sourceforge net
- Cc: gtkglext-list gnome org
- Subject: Re: [GtkGLExt] GTK3: additional considerations
- Date: Wed, 04 Jan 2012 01:55:48 -0500
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]