lkml.org 
[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: State of Linux graphics
    On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote:
    | The real goal is to provide a good programming environment for 2D
    | applications, not to push some particular low-level graphics library.

    I think that's a reasonable goal.

    My red flag goes up at the point where the 2D programming environment
    pushes down into device drivers and becomes an OpenGL peer. That's
    where we risk redundancy of concepts, duplication of engineering effort,
    and potential semantic conflicts.

    For just one small example, we now have several ways of specifying the
    format of a pixel and creating source and destination surfaces based on
    a format. Some of those formats and surfaces can't be used directly by
    Render, and some can't be used directly by OpenGL. Furthermore, the
    physical resources have to be managed by some chunk of software that
    must now resolve conflicts between two APIs.

    The ARB took a heck of a long time getting consensus on the framebuffer
    object extension in OpenGL because image resource management is a
    difficult problem at the hardware level. By adding a second low-level
    software interface we've made it even harder. We've also put artificial
    barriers between "2D" clients and useful "3D" functionality, and between
    "3D" clients and useful "2D" functionality. I don't see that the nature
    of computer graphics really justifies such a separation (and in fact the
    OpenGL designers argued against it almost 15 years ago).

    So I think better integration is also a reasonable goal.

    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.

    Allen
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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