-----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----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/