Re: Why run xserver on the OpenGL API?

Keith Packard wrote:
> Around 14 o'clock on Nov 25, "Kendall Bennett" wrote:
> 
> 
>>Well that is a little different to what was originally proposed. The
>>original proposal was to make X live on top of OpenGL proper and migrate
>>apps and toolkits over to using OpenGL only for all rendering. IMHO that is
>>a bad idea because OpenGL is pretty bad at basic 2D stuff.
> 
> 
> I think there have been several different ideas floating about on the 
> list; I've tried to keep my own interests clearly focused on making the X 
> server more easily ported to new and existing hardware by taking advantage 
> of the GL device abstraction (even if we have to break it a bit in the 
> process).
> 
> 
>>However if the 'device driver' layer is basically an extended OpenGL back 
>>end with extensions for direct framebuffer access and some basic 2D 
>>operations, then that is a different story altogether.
> 
> 
> I don't think there are any new accelerated functions needed in GL for core
> 2D operations; glCopyPixels is sufficient for CopyArea, and all we need
> aside from that is FillRectangles.  There are a few interesting compositing
> operation modifications that could accelerate bits of Render, and may in
> fact be of some interest to 3D applications as well at some point.
> 
> Note that I'm not interested in some 2D subset of GL for hardware 
> incapable of supporting full GL; that's not really helpful at all; 
> creating a 2D subset and then carefully targeting the X server to that 
> seems far more complicated than just defining a simple 2D-specific driver 
> interface for cards that don't have 3D support.  I suspect you know of at
> least on such interface.

I'd agree with this.  Somebody might get a bee in their bonnet about it at 
some later stage, but I can't see it being helpful to the larger task of 
moving things forward.

Keith