State of Linux graphics

[Joe Krahn]

Brian Paul wrote:
> Just a few comments...
> 
> Keith Packard wrote:
> 
>  > Again, the question is whether a mostly-software OpenGL implementation
>  > can effectively compete against the simple X+Render graphics model for
>  > basic 2D application operations, and whether there are people interested
>  > in even trying to make this happen.
> 
> I don't know of anyone who's writen a "2D-centric" Mesa driver, but
> it's feasible.  The basic idea would be to simply fast-path a handful
> of basic OpenGL paths that correspond to the basic X operations:
> 
> 1. Solid rect fill: glScissor + glClear
> 2. Blit/copy: glCopyPixels
> 3. Monochrome glyphs: glBitmap
> 4. PutImage: glDrawPixels
...
OpenGL was designed from the beginning to be efficient at 2D rendering, 
although providing only low-level functions. It can be fast at 2D 
operations due to special-case features, like pixel copy with a 1:1 
scale. Most of these 2D cases are already handled efficiently, right?

The hard part about 2D rendering in OpenGL, in my experience, is having 
to make sure that a vast number of state changes for 3D have not been 
changed. In the purely 2D case, those states should never change.

So, the main problem of 2D OpenGL is having to carry around a lot of 
unused 3D states. How big is an entire OpenGL state structure?

There are a few other OpenGL deficiencies, but isn't it best to get 
those into OpenGL rather than a whole separate rendering path?

Joe Krahn