[cairo] glitz-glx

[David Reveman]

On Mon, 2004-05-24 at 10:32 -0700, Jon Smirl wrote: 
> > > On TEXT2 ATI proprietary shows the background. On SW mesa the background is
> > > black.
> > 
> > The background should be black in cairogears TEXT2 test. What background
> > is shown with ATI proprietary drivers?
> 
> It had the space one. Maybe the buffer wasn't cleared from the previous test?

ah, this is just simple bug in the cairogears program. I use a single
buffered visual for the TEXT2 test and I do incremental drawing of text.
I only clear the background every 1000 "frame". You don't get the
background cleared the first time as cairogears probably starts drawing
before the window is mapped. cairogears should wait for an Expose event
before it starts drawing.

> 
> > 
> > > On the GRAD test the hardware radeon mesa driver is five times as fast as
> > the
> > > ATI driver. When on all of the other tests it is about the same speed. Mesa
> > is
> > > probably skipping something in that case.
> > 
> > ATI's proprietary driver is probably supporting pbuffers and glitz will
> > then use those for offscreen surfaces. For both drivers the gradient is
> > generated by cairo and then sent to video memory. For mesa, which lack
> > pbuffer support, glTexSubImage2D is used for this transfer as the
> > offscreen surface is a texture. For ATI, glDrawPixels is used to
> > transfer the pixel data directly to the pbuffer. It seems like
> > glDrawPixels this isn't as fast as TexSubImage and as we're not using a
> > render_texture extension (GLX_ATI_render_texture is buggy) we need to
> > transfer the pixel data from the pbuffer to a texture before we can use
> > this as a source surface in glitz_composite_trapezoids. This means a lot
> > of unnecessary work and extra memory consumption when using ATI's
> > proprietary driver.
> 
> glDrawPixels is much slower than glTexSubImage2D. DrawPixels goes through AGP
> and SubImage is all on the card.

Both of these functions transfer pixel data from user memory to graphics
hardware, only difference that I know of is that glTexSubImage2D
transfer pixels to a texture and glDrawPixels transfer pixels to a
drawable (maybe you were thinking about glCopyTexSubImage2D). 

I can't see why glDrawPixels would be slower than the glTexSubImage2D.
We can of course use glTexSubImage2D to transfer the image data to a
temporary texture and then just draw that texture to the drawable, but
if that's faster than using glDrawPixels, then it seems to me that the
used OpenGL implementation is doing something kind of stupid.

> Isn't there a way in GLX to point the context's read buffer and write buffer to
> two different buffers and then copy? Read would be pbuffer and write the main
> buffer. ATI definitely supports pbuffers.

yes there is, but that cannot be used in this case as all compositing
operations (including gradient drawing) need to blend the source onto 
the destination.
 
-David