Re: Why run xserver on the OpenGL API?

Around 17 o'clock on Nov 25, John McCutchan wrote:

> Why does an opengl extension need to be written to provide the frame
> buffer access? what do you need that you can't accomplish already with
> glReadPixels () and glDrawPixels ()?

Yes, we can synthesize direct frame buffer access with these two functions
for an unextended GL library, but performance will be dramatically impacted
as I pull huge chunks of the buffer up into the X server, draw a few pixels
and push them all right back again.

A simple direct frame buffer mapping and locking extension will allow us to
run all of the existing dumb frame buffer code without change, dramatically
speeding the migration to an OpenGL-based X server with no negative
performance implications.  Along the way, we may be able to identify a few
kinder looking GL extensions to reduce dependence on the frame buffer
mapping extension -- there are a few X pixel operations not supported by GL
that might make good candidates (plane masks, per-component alpha, conjoint/
disjoint compositing operators).  

If you grant that it's interesting to move the X server to the OpenGL API, 
please grant that it may be worth breaking some of the GL abstractions to 
make the effort more likely to succeed.

-keith