Re: Why run xserver on the OpenGL API?

Around 22 o'clock on Nov 24, Jon Smirl wrote:

> What you don't want to do is make OpenGL an option in the new desktop
> servers. If it is a known fact that OpenGL will be in every freedesktop
> xserver no matter what the hardware, then apps will get written to use it.
> But if OpenGL is an option, few people will write to it - that's the state
> we're in right now. Instead they will stick with the 'standard' xlib API
> because it will be more 'compatible'. Every window created on the xserver
> needs to support OpenGL from day one.

There's a difference between writing an X server that targets GL as the 
underlying device abstraction and pushing applications from the X 
rendering API towards GL.

The former is an implementation detail that seems like a great way to
avoid duplicating a bunch of rendering code in two separate places.  I 
believe we'll want some minor additions to GL to make this easier; in 
particular, the ability to fall back to software for weird 2Dish 
operations will make porting trivial; a slow migration to acceleration
using regular GL function calls is a lot easier to plan than a giant leap 
from touching pixels directly to doing everything through a new API.

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.

Let the application developer select their API, and just make sure that
reasonable APIs map as directly to the hardware as feasible.

> Even if we shipped a fully OpenGL enabled xserver today it will still take
> years for a significant number of apps to get converted. Converting
> toolkits to OpenGL will be a big help. But we need to get the full 3D
> conversion in motion since we don't want to end up five years from now with
> all MS apps converted and nothing happening on Linux. The decision to
> convert the industry to 3D hardware has already been made (because of MS);
> we just have to decide if Linux to going to take advantage of it.

I guess I don't quite understand what you mean by 'converting toolkits'. I
haven't seen very successful 3D user interfaces for general purpose
document preparation/personal productivity software yet, so it seems like
these toolkits will remain functionally 2D for some time to come.

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.

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.

In summary:

 +	Design GL extensions to allow for direct access to the frame 
	buffer.

 + 	Write a GL backend for the X server so that environments with 
	GL drivers need not also provide a 2D driver.

 +	Encourage device driver authors to include support for the above
	mentioned GL extensions in preference to separate 2D backends
	for X.

 +	Encourage 2D applications to consider using cairo for rendering as
	that will allow direct GL drawing while still running on legacy
	systems (which seem to hang around forever in the open source world)

-keith