Re: OpenGL support in GTK+

Naofumi Yasufuku wrote:

At Fri, 19 Sep 2003 10:34:00 -0400,
Owen Taylor wrote:
By making this integration "official", we get advantages that:

- It's clear what to use to use OpenGL with GTK+
- There are less dependency problems. Multiple competing
  OpenGL-for-GTK+ libraries could cause problems if, say,
  a library wanted to use OpenGL.
- We can make sure that the API is something that we are happy with

There are several levels of integration that could be discussed here:

- Make GDK actually link to OpenGL, include a "GtkGLArea" in libgtk proper.
  There are two problems with this:
- First, ever GTK+ application gets a dependency on the
     libGL shared library. The overhead of that is noticeable.
     (Qt does always link to libGL...)

   - OpenGL becomes a build dependency of GTK+. While it would be
an optional build depenency, that means that if you first build GTK+, then build GL, you have to rebuild GTK+ again.

- Include another library in the gtk+ tarball. Has the same
build dependency problem. Doesn't have the problem with making all apps link to libGL.

  Note that there is a libglade integration problem with this,
  as Naofumi points out. Either libglade has to depend on this
  library (pulling in libGL) or this library has to depend
  on libglade (note possible if it's part of GTK+.)

  If we do go ahead and add libglade-like capabilities to GTK+,
  as has been discussed, then that problem goes away. So whether
  this is a problem depends on how things are scheduled.

- Bless an OpenGL library as official (put it on
Has similar problems with libglade integration, since we presumably don't want to bless libglade as official with it's
  current dependency on libxml. (Nothing wrong with libxml,
  but it's large.)

Third level may be a reasonable way to most(?) of GTK+ people (not to

* Keep GtkGLExt as a separate package.

* GtkGLExt library provides new GtkGLArea widget.

* GtkGLExt package provides libglade module (GtkGLExt depends on
  libglade), or libglade supports GtkGLArea widget (libglade depends
  on GtkGLExt).

* Work on glade developers to support GtkGLArea widget (glade depends
  on GtkGLExt).

But, from point of view of a GtkGLExt developer, integrating GdkGLExt
library into GDK seems natural way.

Basically, GdkGLExt API follows GLX 1.3 API (however, current internal
code uses GLX 1.2 for portability).

 Display *display;
 Window window;
 GLXFBConfig fbconfig;
 GLXWindow glxwindow;

 window = XCreateWindow (display, parent, ...);
 glxwindow = glXCreateWindow (display, fbconfig, window, NULL);
 GdkWindow *window;
 GdkGLConfig *glconfig;
 GdkGLWindow *glwindow;

 window = gdk_window_new (parent, ...);
 glwindow = gdk_gl_window_new (glconfig, window, NULL);

Programmer have to take care to keep a pair of window and glwindow, so
GdkGLExt library provides gdk_window_*() extension functions which
add OpenGL support to GdkWindow.

 GdkWindow *window;
 GdkGLConfig *glconfig;
 GdkGLWindow *glwindow;

 window = gdk_window_new (parent, ...);
 glwindow = gdk_window_set_gl_capability (window, glconfig, NULL);


 void a_func (GdkWindow *window)
   GdkGLWindow *glwindow = gdk_window_get_gl_window (window);

gdk_window_set_gl_capability() creates new GdkGLWindow, then set it to
GdkWindow's qdata. GdkWindow supports OpenGL, and programmer can add
OpenGL-capability using set_gl_capability(). If GdkWindow is
OpenGL-capable, get_gl_window() returns GdkGLWindow. The same thing is
also provided for GdkPixmap and GdkGLPixmap.

I think it will be much help for adding OpenGL support to the existing

If people don't need maximum flexibility, and don't like such
extension functions, GdkGLExt library should be kept out of GDK.


> Programmer have to take care to keep a pair of window and glwindow, so
> GdkGLExt library provides gdk_window_*() extension functions which
> add OpenGL support to GdkWindow.

I dont understand why the application programmer should have to manage 2 GdkWindow's. Why not have a GdkGLWindow that derives from the GdkWindow and implements the
GdkWindow in an OpenGL fashion ?

Could the same be done for a GdkGLGC ? (and a GdkGLConfig could be a delagate
of the derived GdkGLGC ?)

This way GdkGL could be integrated into Gdk without any extra mucking around with numerous drawables and extention functions, There would be little or no need for Gtk+ widgets to have a dependancy (if theese objects were implemented as a seperate library which extends gdk), And an already existant gtk+ application could become OpenGL driven after a little mucking around in the theeme engines (styles and gtkrc's

basicly, if you want to know if your widget has OpenGL capability:

if (GDK_IS_GLWINDOW(widget->window)) {
   /* I have a gl window */

I have to admit, I only sifted through this code a little (just the headers and a few examples) so maybe I missed something that makes this approach impossible but it seems to me to be
the most intuitive way.


  I must of overshot the subject scope, maybe this mail should be
               "OpenGL in Gtk+ implementation RFC" ?

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