Re: OpenGL support in GTK+

[Naofumi Yasufuku <naofumi yasufuku net>]

At Tue, 23 Sep 2003 09:42:25 -0400,
Tristan Van Berkom wrote:
> 
> 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+).

I don't agree on that. OpenGL is only a set of low-level drawing
commands. It doesn't provide functionality for a GUI toolkit
(for example, font management and glyph rendering, convenient clip
region management, setting window's background pixmap, etc.).

OpenGL-based windowing system would be nice (e.g. Apple's Quartz
Extreme, Berlin, OpenGL-based X Window System some people are working on),
but I don't think GTK+ should be entirely OpenGL-driven.

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

I think it is not realistic that all GUI components are drawn using
OpenGL drawing primitives...

(However, it may be nice to treat GUI components as texture and
composite into a top-level window using OpenGL (like Apple's Quartz
Extreme treats all windows as texture). Though it sounds an ambitious
attempt, I think it is not impossible. Double-buffered GTK+ widgets
are drawn on off-screen pixmap, then the pixmap is drawn on window.
Anyway, it is beyond the scope of this thread.)

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

I believe that GtkGLExt's GdkGLWindow is practical solution.
GdkGLWindow is a GL drawable which has an associated GdkWindow
(GLXWindow is a GLXDrawable which has an associated Window).

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

Why do we need to create X GC for OpenGL rendering?
Why do we need to configure OpenGL frame buffer for X drawing?
If GdkGLContext "is a" GdkGC, inheriting from GdkGC is right, but
GdkGLContext "is not a" GdkGC.

Regards,
--Naofumi