Re: OpenGL support in GTK+

[Tristan Van Berkom <vantr touchtunes com>]

Naofumi Yasufuku wrote:
> [ snip ]

Hi, and sorry for the late response...


It would be nice if we could get any application written in gtk+ to be
OpenGL driven without modifying the application code, I think we can
all agree on that (although its not as important as simply having a portable
GL api that is easily accessable through gtk+).

> 1. I developed GdkGL* objects to be able to use with *EXISTING* code.
>   If GdkGLWindow is a subclass of GdkWindow, we have to override
>   realize method of existing widget classes. It means that OpenGL can
>   be used only with widgets specialized for OpenGL.
All the realize methods use a standard interface to allocate resources for
standard drawing, they use the GdkWindow api, now; if automagicly
gdk_window_new() started returning a GdkWindowImplGLX11 or
a GdkGLWindow that respected the same interface but implemented
it in OpenGL....
             Anyway, I'm not so sure that that is the goal of this
exercise, but this type of aproach would probably help keep applications
as lightweight as possible, (i.e. imagine a GUI entirely in OpenGL Gtk
widgets; whatever the context, every widget is going to either have its
own Drawable or even worse, it will have its own drawable && its
own GLDrawable ?).

> 2. I think it is hard to derive from GdkWindow. GdkWindow is not
>   simple new(type, properties...) style GObject in contrast with
>   GTK+ widgets. GdkWindow is not intended to be a base class. At
>   least, deriving from GdkWindow is impossible in external library
>   without duplicating gdkwindow-x11.c code - it will be a nightmare.
>   (Owen, is it right? correct me if I'm wrong.)
Yes, it will be a nighmare, That code would have to be bent into a
more desireable shape. gdk_window_new would have to be some
kind of  `meta class' kinda thingy (it would have to decide whether
to return a GdkWindowImplX11 or a GdkWindowImplGLX11, or
the windoze equivalents....)

> So GdkGLWindow is not GdkWindow (but another GdkDrawable for
> convenience. In current GdkGLWindow implementation, GdkWindow is a
> delegate object for GDK drawing.), and simply follows GLX 1.3 API.
>  

A GdkWindow is a GdkDrawable (only it doesn't really exist). For some
reason I cant seem to find the definition of GdkWindow but I'll bet its in
some header generated during the build process. It's probably defined
to GdkWindowImplX11 or simply GdkWindowObject.

I still dont understand why the GdkWindowObject should hold
a ptr-to-drawable instead of having the GdkWindowImplX11
implement the GdkDrawableClass methods directly (somehow
seems redundant to me, maybe a build issue ?).

> > Could the same be done for a GdkGLGC ? (and a GdkGLConfig could be a 
> > delagate
> > of the derived GdkGLGC ?)
> >    
>
> I don't understand. We cannot set colormap, foreground/background
> color, fill style, and so on, to the OpenGL rendering context.
> GdkGLContext is not GdkGC.
Why not ? All that would be done would be to extend to api to handle
OpenGL context specific stuff and use the already existant members
of the GdkGC instance to implement the basic drawing methods of
the GdkDrawable.


Cheers,
                               -Tristan