State of Linux graphics
krahn at niehs.nih.gov
Thu Sep 1 09:04:32 PDT 2005
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?
More information about the xorg