Xegl lives!

[Allen Akin]

On Thu, May 26, 2005 at 12:01:51PM -0400, David Reveman wrote:
|                                                    ... it's not like
| it's a completely new model, it's very similar to PostScript, PDF, SVG,
| Quartz...

That highlights both the strengths and weaknesses pretty well.

PostScript-like rendering has been well-established for a long time,
people are comfortable with it, and a lot of software is based on it.

However, it was created in an era when the processing demands for
printing were greater than the processing demands for interactive
display, antialiasing was considered exotic technology, and the fanciest
graphics hardware around could only do pattern-fill of scan-line-aligned
trapezoids.  The tradeoffs that made sense in such an environment aren't
always good today.

Supporting the old rendering model in some way on new hardware is a
necessary thing, though I believe doing *only* that leaves a lot of
functionality and performance on the table.  The first people who learn
to make all the GPU transistors really sing will produce
paradigm-changing systems.

| I think it's much better to create an API design for an imaging model
| that is hard to accelerate right now but what application developers
| want for the future than to create an API that is well accelerated today
| but uninteresting to application developers in a year or so.

I agree up to a point.  I think we have a pretty good understanding of
hardware capabilities that'll be common during the next ten years or so.
It's fine to design an API that isn't highly accelerated today, so long
as it soon can be.

But to make the process *really* effective, you need commitment in two
directions.  Low-level API designers should support app developers'
requests to the extent possible.  And higher-level developers will
produce better systems if they can make their requests fit within the
characteristics of the hardware.

Some examples:  Drawing geometry offers more transformation flexibility,
more general antialiasing, and higher performance than pushing pixels.
Avoid low-level API concepts that require nonsequential access to
vertices or pixels, or unbounded amounts of intermediate memory.  Don't
lock yourself into fixed-function designs; expose and take advantage of
the programmability of the GPU.  And so on.

It's an interesting time, because everyone is just beginning to realize
how much untapped potential for non-gaming apps exists in commodity
GPUs.  Longhorn appears to be the first broad systematic attempt to
exploit it, but a lot more remains to be done.

Allen