Jim,

> No matter how fast you hope to render into host memory, it 
> will continue to be much slower than if you can render in
> display memory, on screen or off screen, on the graphics cards. 

Absolutely. But this wasn't my point. My point was rather that if you
can _not_ use hardware for some specific operation and need to do the
operation close to the end of the pipeline it is extremely nice to make
use of the "fast path" where you can and then do your own compositing.
So with the appropriate extensions you can use OpenGL for everything
that it can handle while being capable of doing any remaining stuff for
yourself (and reasonably fast). It will be slower than having the
hardware do it all for itself - but it's still going to be way faster
than having to do it all on your own. It's a nice win-win situation.

> Example: with the nice alpha compositing in software we now 
> have, compared with very early hardware assisted implementations, 
> the difference can be that of a factor of 20 or 30 or more in
> performance.  This was actually somewhat higher than we first
expected...

Actually, it's somewhat slower than I would have expected ;-) But maybe
I'm just so used to the latest generation of graphics cards with all
these parallel pipes...

> The amazing thing is that current CPU's are "fast enough" to do it in
> software for a large class of operations.

And then, there's always memory to throw at it. Considering that "small"
machines these days have more memory than my desktop machine a few years
ago it's always worthwhile to do some agressive caching.

[Re: Artifacts]
> Whether or not this is really true is an interesting discussion. 
> When Render really got started up 18 months ago, I did not see Alan
> Akin dispute this accusation (who very much is a 3D person and
> participated in alot of the discussions); but as I said, I'm not an 
> openGL/3d person myself.

This might be due to non-compliant implementations. The last time I
looked at it (which is some years back) Mesa did fail a number of
rasterization tests (due to speed optimizations) and something like this
might well be the cause of it. Can't say for sure without having
concrete examples but OpenGL does specify very strict rasterization
semantics (on the other hand, come to think of it, I am uncertain if
they are "strict enough" for something like a really large smooth
gradient spanning the entire background of some window).

> Another major issue is that devices like PDA's aren't going 
> to see usable OpenGL implementations in any finite time: the
> hardware lacks both floating point and any way to get much
> hardware assist at all. 

Well, if you would put in a graphics chip you'd have no need for other
floating point hardware would you?! ;-)

> The limitations on PDA's and low end appliances
> won't change in the next 2-4 years, in my opinion. 

Not until there's some amazing new power technology waiting around the
corner. NVidia made some good progress with reducing power consumption
in their laptop chip sets but it's still nowhere near usable in your
average cell phone...

> My gut feel is that 3D will be similarly slow: on battery
> devices you aren't just bound by memory costs, but also on power;
> this implies that any 3D graphics chip just isn't going to happen
> by taking desktop chips and putting them in PDA's.

Dunno. You are only taking the "objective" factors into account - but
what if there would be a dedicated game device with some killer app that
gets millions of kids into wanting such a device?! Something in the
GameBoy range perhaps...

> > Interesting. Will there be versions for Windows, Mac etc. as well?!
> 
> If someone does it...  Given that one code path goes to 
> pixels, the rendering clearly has to switch between local
> pixels to be pushed vs. letting a window system do it for
> you, so it should be doable to other window systems.
> 
> But I suspect some X'isms would be in the current API, though 
> they are making it look very postscriptish...  Things are still
> early enough to influence, at this date. 

So where's the place to go to for this discussion?!

Cheers,
  - Andreas