Re: Why run xserver on the OpenGL API?

Jon Smirl wrote:
> --- Keith Packard <[email protected]> wrote:
> 
>>The latter is a much stronger statement that encourages/forces application
>>developers to migrate to a strange and possibly inappropriate graphics
>>model.  Far better is to provide appropriate glue between the API they want
>>to use and the graphics hardware, let them use GL where appropriate, and
>>also provide support for cairo and xlib.  Cairo is a clean 2D API that can
>>live atop either xlib, Render or GL, and exposes a full PDF 1.4 rendering
>>model which is as close to 'complete' as we've seen in a 2D API.
> 
> 
> My understanding is that Cairo is a retained mode interface and OpenGL is an
> immediate mode one. So we are comparing apples and oranges.  Maybe someone can
> elighten me, why is Cario being designed instead of just using the SVG API? Is
> Cairo going to be integrated with stylesheets like SVG? If not, what good is
> this to the browser developers?
> 
> 
>>Let the application developer select their API, and just make sure that
>>reasonable APIs map as directly to the hardware as feasible.
> 
> 
> My goal is to ensure that OpenGL is available on every Linux desktop as soon as
> possible. A big reason we don't have Linux games is that the status of OpenGL
> support under Linux is pretty chaotic. A pervasive OpenGL API is the key to
> getting mainstream apps to use it, but it will take years of deployments before
> this happens. This says nothing about using the Cairo API, Cairo is retained
> mode which is a different beast,
> 
> 
>>So, if you just mean migrating to using GL for 2D rendering, then I think
>>that's a bit pushy, and I would rather see us build a system that gets from
>>whatever 2D api the developer is using to the hardware as conveniently as
>>possible.  For existing applications, we want the X server to map X
>>rendering calls to GL function calls, for new applications I'd really
>>rather see them written to cairo which can use GL where available, and fall
>>back to either Render or the core protocol where necessary.
> 
> 
> It it better to write a toolkit to Cairo and then have Cairo convert to GL, or
> is it easier to just write the toolkit to use GL? This is assuming that the
> toolkits already have xlib support.
> 
> Another obvious point is that since GL doesn provide fonts, a font library is
> needed. Would this be provided by Cairo? Can I freely intermix GL drawing and
> Cairo to the same window?
> 
> 
>>Of course, I do hope to see interesting 3D applications developed as well,
>>and those would be ill-served with a 2D-centric API. I think it's
>>reasonable to assume that systems using 3D applications will have hardware
>>capable of supporting full GL; we know that essentially all hardware will
>>provide that in the coming years.
> 
> 
> We differ here. Becuase of what Microsoft is doing there won't be a distinction
> between 2D and 3D in five years. MS is dropping their pure 2D API in favor of a
> 2D/3D combo API. OpenGL is an equivalent 2D/3D combo API. Their 3D API is always
> available even if software rendered.
> 
> keithw/brian may be able to comment more on this. Could we define a 2D API out
> of the existing GL API and then guarantee that it will be accelerated on 2D
> hardware. The rest of the 3D API would still be there via Mesa. This would give
> apps concerned about performance on 2D only hardware an API set that is
> guaranteed to still be accelerated. 

What would constitute the "2D API"?  glDraw/Read/CopyPixels(), 
glBitmap?  Line/polygon drawing?

There's no reason why glDrawPixels, glCopyPixels, etc. can't be 
hardware accelerated for the common cases.  It's just always been a 
lower priority than the 3D stuff (given limited resources).

-Brian