[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: State of Linux graphics
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
Version: GnuPG v1.2.6 (GNU/Linux)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-31 22:31    [W:0.099 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site