Re: Why use OpenGL (was Native Mode Handling)

Kendall Bennett wrote:
> [This is my original post that I forgot to post to the list]
> 
> Jon Smirl <jonsmirl-/[email protected]> wrote:
> 
> 
>>4) xserver modified to use the GL API.
> 
> 
> Honestly I don't see the point of building an X server to live on top of 
> an OpenGL implementation. At the lowest level OpenGL is broken down into 
> two components - buffer/surface management and the rendering engine. As 
> long as the surface management is cleanly shared between the 2D engine 
> and the 3D engine (and the Video engine for that matter), you don't need 
> OpenGL itself for implementing 2D X server functionality.

Sure, but we want to go beyond traditional 2D X server graphics.


> One argument might be that OpenGL gives you all kinds of cool blending 
> operations via the 3D engine, but OpenGL itself is completely overkill 
> for this purpose. Rather what you need is to expose new 2D functionality 
> (blending in hardware basically, to form a compositing window manager) 
> but underneath the X server implements it using the 3D engine 
> capabilities of the hadrware. You don't need a complete OpenGL pipeline 
> to be able to do cool 2D stuff in the X server or window manager. Even if 
> you went so far as to want 3D transformations for window buffers, you 
> still don't need OpenGL for that either. Basic 3D transformations on 2D 
> surfaces is really simple, so a simple geometry pipeline (possibly in 
> hardware) combined with a simple triangle renderer in hardware is all you 
> need. Building it simple at the 2D level means you can also build the 
> software only version more easily and it will be significantly smaller 
> than a complete OpenGL rendering pipeline. You don't need mip-mapping, 
> multi-texturing, vertex shaders, pixel shaders, display lists, selection, 
> picking, stencil buffers etc for a 2D window manager. 

Actually, I can anticipate uses for multi-texture, mipmapping, pixel 
shaders, etc. in the window system.

Designing an OpenGL subset is actually a pretty arduous task.  If 
you've followed the OpenGL ES project you know how every little thing 
gets debated to death.  Everyone has a different idea of what's needed.

I also think that going from a minimal OpenGL-like rendering pipeline 
to a full OpenGL implementation isn't that big of step.


> Also if you take that approach, OpenGL is just another rendering engine 
> that can draw stuff into offscreen memory buffers (as is the 2D engine 
> and Video engine). Then you can do 2D, 3D and Video all together into a 
> video memory buffers and composite them all together to form the final 
> desktop. Flicker free, translucent and smooth ;-)
> 
> Oh wait! I am just describing OS X ;-)

-Brian