Re: GtkGLExt (was Re: Gtk 3.0)

[Ralf Corsepius <rc040203 freenet de>]

On 12/05/2009 12:28 AM, Emmanuele Bassi wrote:
> On Fri, 2009-12-04 at 18:11 -0500, Braden McDaniel wrote:
>
> I have the impression that my message is not coming through correctly,
> because I keep saying the same things. :-)
>
> > > 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.
>
> yes. and that, apart from games and scientific/technical applications,
> it's not at all common.
>
> >   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.
>
> which dependency chain? it's the same as gtk+.
>
> > > 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.

Agreed.

> the amount of code using OpenGL is relatively limited
Correct - Now ask yourself why.

IMO, the causes historically have been and are:
- Lack of usable drivers, esp. on Linux.
- Demands on CPU-powers (10 years ago, even simple wire-frame graphics 
were a CPU challenge on Linux).
- For most desktop applications 2D is sufficient, even less need 
"advanced 3D".

Historically, these reasons were both causes for GUI-toolsets (such as 
Gnome) to favor other toolset libs on their low levels in favor of other 
toolset libs.

The situation would be entirely different today, if Linux had performant 
OpenGL drivers and if GUI toolchains would have based their graphics 
works directly on OpenGL (or any other performant, low level 3D graphics 
API).

> Clutter is a new project, compared to OpenGL, and yet *it's* *not*
> intended to cover the same usage of OpenGL. its intended use covers a
> canvas for writing applications, not molecule viewers or 3D shooters.
Future will tell if this isn't much more than "yet another 3D library" 
amongst those many already existing ones ;)

> that's why GtkGLExt can still be perfectly fine outside of the gtk+
> codebase; it provides much more than setting up a GL context, which
> would be the agreed API for gtk+ to expose, and given the amount of
> applications actively requiring to drop into GL without any sort of
> canvas, then it might make sense to keep GtkGLExt exactly as it is.
Agreed. Besides fixing bugs and reflecting Gtk API changes to it, I 
don't see much reasons for changing anything.

Ralf