Re: Why run xserver on the OpenGL API?

Around 19 o'clock on Nov 25, Dave Dodge wrote:

> Consider that if they aren't open source, some Linux distributions simply
> will not include the drivers even if they exist. So while you may have
> OpenGL on every Linux desktop, it may not be hardware accelerated on every
> desktop even if drivers are available (unless the owner does the extra work
> of finding and installing the add-on drivers). Which is pretty much the
> current situation.

That's why it's reasonable to provide a portable library interface between 
applications and the underlying graphics hardware interface layer.  

Requiring OpenGL on open source platforms just isn't practical in the near
term.  Taking advantage of OpenGL where available is certainly to be 
encouraged though, the current mindless duplication of rendering code is 
only slowing down development and making distribution and deployment far 
too difficult.

The best route I see is to provide mechanisms that offer good 2D interfaces
(or at least popular ones) that can be trivially mapped to OpenGL, while
still permitting reasonably performant implementations on core X or Render
systems (along with other window systems, printers and even in-memory
images).  It's not that OpenGL doesn't expose the hardware capabilities and
offer good performance for what 2D applications want, it's that
applications demands extend beyond high performance screen-oriented
graphics.

We need to offer interfaces that application developers want to use.
So far we've had a very good reception for cairo in that community.  It's 
not fundementally different from OpenGL at the basic rendering level (as 
evidenced by the OpenGL back end), but it is dramatically closer to what
2D applications actually want to do, and (perhaps more importantly), 
offers operating system and output device independence, solving a 
significant porting effort seen by application developers working on 
projects such as OpenOffice, Mono, Mozilla and Gnome.

-keith