Re: OpenGL support in GTK+

[Tristan Van Berkom <vantr touchtunes com>]

Naofumi Yasufuku wrote:

> At Fri, 19 Sep 2003 10:34:00 -0400,
> Owen Taylor wrote:
>  
>
> [snip]
>  
>
> > 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 ftp.gtk.org.)
> >   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
> me).
>
> * 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).
>
> X11
> ----------------------------------------------------------------
>  Display *display;
>  Window window;
>  GLXFBConfig fbconfig;
>  GLXWindow glxwindow;
>
>  window = XCreateWindow (display, parent, ...);
>  glxwindow = glXCreateWindow (display, fbconfig, window, NULL);
> ----------------------------------------------------------------
> GDK
> ----------------------------------------------------------------
>  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
> code.
>
> If people don't need maximum flexibility, and don't like such
> extension functions, GdkGLExt library should be kept out of GDK.
>
> Regards,
> --Naofumi
>  

> 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
etc..).

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.

Cheers,
                                -Tristan

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