State of Linux graphics

[Matthias Hopf]

> > 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.
> 
> 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.

In order to have these extensions supported by other vendors you will
have to go through the ARB, and that can be rather painfull.
On the other hand, OpenGL has gotten better WRT overhead (vertex buffers
etc.).

> 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

? I've never seen them vanish. In 3D there have always been a number of
papers, with Inventor and Performer in the early nineties, and the open
source scenegraphs OpenSceneGraph and OpenSG in the late nineties and
early 21st century. Additionally, all game engines implement their own
scene graph API.

> 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.

None of them think of 2D operations at all. Additionally, many of them
do things you will never want to include in a GUI library, and are thus
pretty much bloated (like OpenSG).

Building a scene graph library can be pretty easy, or insanely complex,
depending on what exactly you want to acchieve and how flexible it
should be.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de