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
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
