State of Linux graphics

[Ian Romanick]

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

Allen Akin wrote:

> I believe we're doing well with layered implementation strategies like
> Xgl and Glitz.  Where we might do better is in (1) extending OpenGL to
> provide missing functionality, rather than creating peer low-level APIs;
> (2) expressing the output of higher-level services in terms of OpenGL
> entities (vertex buffer objects, framebuffer objects including textures,
> shader programs, etc.) so that apps can mix-and-match them and
> scene-graph libraries can optimize their use; (3) finishing decent
> OpenGL drivers for small and old hardware to address people's concerns
> about running modern apps on those systems.

I think that you and I are in total agreement.  I think #1 is the first
big barrier.  The problem is that I haven't seen a concrete list of the
deficiencies in OpenGL.  Before we can even consider how to extend the
API, we need to know where it needs to be extended.

I'd really like to see a list of areas where OpenGL isn't up to snuff
for 2D operations.  Ideally, items on this list would be put in one (or
more) of four categories:  missing (support for the required operation
is flat out missing from OpenGL), cumbersome (OpenGL can do it, but it
requires API acrobatics), ill defined (OpenGL can do it, but the spec
gives implementation enough leeway to make it useless for us), or slow
(OpenGL can do it, but the API overhead kills performance).

Having such a list would give us direction for both #1 and #3 in Alan's
list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDFhEmX1gOwKyEAw8RAiypAJwL/3RpnF10NwGX/hMyumPtMwAbcQCeIXWN
QUzBkYEbSXOKrI0MXIO84Pg=
=tPYg
-----END PGP SIGNATURE-----