State of Linux graphics

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias Hopf wrote:
> On Aug 30, 05 14:13:35 -0400, Jon Smirl wrote:
> 
>>some of the problem in the current server. As described at the end of
>>the paper a new server design would feature OpenGL as it's primary
>>API, xlib would still be supported but at a secondary status.
> 
> I wouldn't do that. OpenGL is not really a suitable API for rendering
> 2D.  It's too low level, and overhead is too high (you have to change
> tons of render states all the time).  Render is much better for that.
> 
> Maybe we should look into a scene graph API for mixed 2D/3D GUIs.
> Avalon is doing it, maybe it's a wise decision.  Whether XML is remains
> to be seen.  But I don't remember whether XML is transmitted to the
> graphics engine, or whether it is only used for storing/designing the
> GUI elements.

I have a couple comments about this.

As it currently exists, OpenGL isn't very well suited to intensive 2D
rendering.  You are correct that the API-call overhead is quite high.
However, since we control the driver for a number of cards, we can
create whatever extensions we need to get the job done.  That's one of
the strengths of OpenGL.

If we implement a couple fast-path functions and the X-server gets a
significant performance boost from them, the hardware vendors will
support them.  There's even a good chance they could get incorporated in
a future core version of OpenGL.  This has happened with Mesa extensions
in the past (GL_MESA_window_pos became GL_ARB_window_pos, which was
incorporated into OpenGL 1.4).

Scene graphics were the big thing some years ago, and it looks like
they're making a comeback.  This is another area where we can probably
leverage the work of others.  There are several existing scene graph
libraries (that already work with OpenGL).  I haven't evaluated any of
them, but the odds are fair that at least one will be suitable for our uses.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDFeisX1gOwKyEAw8RAmwWAJ9NjDS1ozKSFkHdo68D9mTTDnG0TACfSkPR
P9ZrmiJ4GsCejTmGpeV2Ttk=
=0p+z
-----END PGP SIGNATURE-----