[cairo] Large number of glReadPixel method calls

[David Reveman]

On Wed, 2004-07-28 at 10:13 -0600, Charles Tuckey wrote:
> Hi David,
> 
> The latest version of Glitz gets rid of the major leak on all our 
> systems. However, the Matrox (XiG driver) system runs our application 
> very, very slowly and uses quite a bit of CPU. The XiG driver has a 
> great feature - we can set an environment variable and it prints out all 
> the GL calls that are being made. When we did this, it appears as though 
>   a call to glReadPixels() is the bottleneck. When running our memory 
> leak test program (see Possible Memory Leak Using Glitz Surfaces) we see 
> that this method is called after every call to cairo_show_text.
> 
> Do you have any suggestions? Is the call to glReadPixels() a direct 
> result of what's being done in the glitz library or is it a side effect 
> generated by the XiG driver?
> 
> If it would be useful to you I can send the log of all the GL commands 
> generated by the XiG driver.
> 
> FYI, here is what the XiG support person had to say:
> 
>     glReadPixels() should be used sparingly because it can cause the
>     entire GL rendering process to halt while it synchronizes and fetches
>     data from the card.  I notice the ReadPixels is over a relatively
>     'huge' area:
> 
>       'glReadPixels(x=0, y=0, width=400, height=400, format=80e1, 
> type=1401, pixels=50ab4008)'

The latest version of glitz, handles alpha surfaces more correctly. In
earlier versions of glitz, internal texture format GL_INTENSITY was used
for alpha textures, now GL_ALPHA is used instead. This change was
necessary to make alpha surfaces work as they should. However, the
GL_ARB_texture_env_combine extensions is now required for compositing
using a GL_ALPHA texture as mask.

I'm guessing that the matrox XiG driver doesn't support this extension,
which
means that cairo will fall-back to software rendering of every glyph
(reading
the complete destination surface with glReadPixels into a local image
buffer,
render the glyph to this image buffer and then transfer the result back
to the
destination surface).

If the matrox XiG driver supports the GL_ARB_texture_env_combine
extension,
then there's a problem with glitz and it should be fixed.
GL_EXT_texture_env_combine should also be fine but glitz doesn't check
for this one right now (I'll fix this).

If none of these extensions are supported by the matrox XiG driver, then
it's not much we can do. Glitz can't render text efficiently without
them.


I'm currently working on some very promising code, which I'll probably
commit in a few days. But it looks like the following set of OpenGL
extensions will be relevant for
the performance and capabilities of glitz.

OpenGL 1.2 will probably be required.

GL_ARB_multitexture
GL_ARB_texture_env_combine or GL_EXT_texture_env_combine
  Without these glitz can't do much more than polygon rendering and
simple
image compositing.

GL_ARB_texture_env_dot3
  This is required for component-alpha.

GL_EXT_texture_rectangle or GL_NV_texture_rectangle
GL_ARB_texture_border_clamp
  These will make glitz run much more efficiently.

With the above extensions available glitz will run very well.

GL_ARB_vertex_program
GL_ARB_fragment_program
  Needed for special image filters (convolution filters, gradient
filters)

GL_ARB_texture_non_power_of_two
  Wow.
 
-David