Re: GtkGLExt (was Re: Gtk 3.0)

[Braden McDaniel <braden endoframe com>]

Emmanuele Bassi wrote:
> On Fri, 2009-12-04 at 20:51 +0000, Carlos Pereira wrote:
> > Hi Emmanuele,
> > > I'm really not working on it - mainly for three reasons: 1) if you want to
> > > use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
> > > good idea;
> > 1) If you think GtkGlExt should not be integrated with GTK+ that's fine 
> > for me.
> >
> > 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt.
> >
> > 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and 
> > SINGLE_INCLUDES...
>
> I guess that you'll have to patch GtkGLExt, and submit patches for
> integration upstream.

We're interested.

We're currently planning what might go into the next GtkGLExt release. 
We probably need to have a discussion about whether there should be 
another release targeting Gtk+ 2.x.

I'll open this up on the gtkglext-list shortly.

> > 4) Scientific/engineering applications often use OpenGL, which is a well established, well documented, 
> > industry-standard with a large, vibrant community, as these foruns clearly show:
> >
> > http://www.opengl.org/discussion_boards/
>
> I never said that raw OperGL is not used, or not useful; I just contend
> that being able to  drop into GL directly is a niche usage - and it's
> not getting any more mainstream.

It is a common requirement for apps that want to do 3D rendering with a 
cross-platform codebase.  Biting off Clutter and its dependency chain is 
not something developers of such an app are likely to want to incur; and 
Clutter probably won't provide adequate functionality in a lot of cases.

> people flee from OpenGL in disgust, and it's just OpenGL 3.x that's
> making some progress towards fixing the insane API that it exposes -
> unfortunately, no GL implementation provides the 3.x API yet.

For a lot of people using OpenGL (or various engines/wrappers like 
OpenSceneGraph and OGRE), there's no practical alternative to flee to.

> the most people care about, as I said, is being able to accelerate
> drawing primitives and blending modes and hand them over to the GPU;
> mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and
> cairo-drm.

The volume of code currently using Clutter, cairo-gl, and cairo-drm 
would be dwarfed by that using OpenGL directly.

I think your use of the term "niche" is a little unusual.

> even if (and I'm saying *if*) GTK+ provided GL integration for
> GdkWindows it would basically boil down to two functions:
>
>   void gdk_window_gl_begin (GdkWindow *window);
>   void gdk_window_gl_end (GdkWindow *window);
>
> plus a way to set up the GL context. that's mostly agreed upon, if you
> read the bug that Javier linked in his email. that's not even close to
> the API exposed by GtkGLExt.

This is certainly a conversation that I'm interested in having.  We're 
certainly aware that there's a good deal of chaff in the GtkGLExt API 
needs culling.  On the other hand, what you're describing isn't *that* 
far from the parts of GtkGLExt that people actually use.  (Well, 
currently the API has users make_current and then do the begin/end stuff 
at the GL level.)  But I'd like to get us a bit farther along in doing 
that paring down before discussing this in depth.

--
Braden McDaniel                      e-mail: <braden endoframe com>
<http://endoframe.com>               Jabber: <braden jabber org>