Re: DRI integration

Keith Packard wrote:
> Around 15 o'clock on Nov 13, Brian Paul wrote:
> 
> 
>>I'm still wondering which primitive X operations (like blitting or 
>>text rendering, etc) might be difficult to map onto GL in your opinion.
> 
> 
> Oh yeah, if I recall correctly, GL doesn't allow me to copy pixels within a
> single object.

Sounds like glCopyPixels.  glCopyPixels can also move pixel blocks 
between different color buffers if your GLX supports "make current read".


> That's a problem for applications which don't repaint for
> scrolling.  For 2D graphics, this is really *the* performance limiting 
> operation; nothing else is "too slow" in software today.  Frankly, a 
> simple bitblt primitive without even a rasterop would be more than 
> sufficient here.
> 
> Text isn't too bad; certainly we could make it a lot faster if we 
> provided some level of acceleration, but realistically, you draw text by 
> constructing a composite image from the individual glyphs, uploading that 
> to the graphics card and using it as a mask for rendering.  Simple AA (and 
> non-AA) text are probably going to be plenty fast with regular GL 
> operations.  Again, per-component composited text will either require 
> software rendering (which runs about 50000 glyphs/sec today) or extensions 
> at the bottom of the GL pipeline.

What is "per-component composited text"?  I'm thinking of GL blending.

-Brian