Xgl/Xegl future?

[Allen Akin]

On Mon, Aug 22, 2005 at 10:38:56AM +0200, Lars Knoll wrote:
| On Monday 22 August 2005 03:08, Owen Taylor wrote:
| > I can't speak for other major toolkits, but there is no current plan
| > to do this for GTK+...
| ...
| And speaking for Qt I can only agree. You can't make all your 2d apps GL 
| based, and we currently don't have any plans to do so. 

Just for completeness, I'll mention once again that there *are*
arguments for doing just that.

Huge amounts of effort are invested in putting transistors on silicon to
support OpenGL and D3D.  By failing to take full advantage of that
investment, you leave both performance and functionality on the table.
In particular, choosing a fixed-function API when the underlying API is
programmable imposes a major restriction on present and future
applications.

As people become aware of new functionality that they'd like to use at
the application level, it becomes necessary to add to the toolkits.  The
added features inevitably duplicate features or concepts found in
more-functional lower-level APIs, but often with subtle differences.
The result is semantic mismatches that make layered implementation
difficult, or encourage the development of parallel low-level APIs
"because we just need these few things; we don't need all of OpenGL."
(RENDER and EXA are current examples of this effect.)  Implementation
resources are scarce in the Open Source world, and this extra effort is
expensive -- expensive enough that it can prevent important projects
from being completed.

The notion that "2D" and "3D" APIs are drastically different hasn't been
true for a long while.  Effects that you'd like for 2D apps leverage
much of the functionality that's nominally 3D (like texture mapping and
geometric transforms, among many other things).  It's fairly difficult
to design a "2D-only" API that's competitive with the sort of integrated
APIs that OpenGL and D3D have become; you have to incorporate a lot of
what they do.

It's often said that OpenGL is too bulky for small devices or old
hardware.  Yet small commercial implementations of OpenGL exist, and all
new devices of cell-phone complexity or greater have decent support for
it.  Putting the highest priority on obsolete hardware does offer
advantages to the people who already own that sort of hardware, but it
doesn't position you to take advantage of the growth in installed base
that results from new hardware being sold into new markets.

Finally, whatever its faults, OpenGL is a standardized multiplatform API
with a management process already in place.  If you believe standards
improve software longevity and increase the number of platforms on which
applications will run, you have to ask yourself whether it's best to
cover up a standard with another API that's not as widely supported, or
simply use the standard API.

If you were to go down the route these arguments suggest, you'd take the
OpenGL or OpenGL ES API as a start, then add utility libraries that are
fully integrated with and described in terms compatible with OpenGL, and
if necessary add OpenGL extensions to provide missing hardware-level
features.  Applications would simply make mixed OpenGL and library calls
to do their drawing, rather than invoking a completely layered API.
It's a perfectly valid way to proceed, if you're inclined to do so.

Allen