[cairo] Large number of glReadPixel method calls

[Charles Tuckey]

Thank you for your detailed reply David. Some comments/questions are below:

David Reveman wrote:
> On Wed, 2004-07-28 at 10:13 -0600, Charles Tuckey wrote:
> 
>>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.
>>
> 
> 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).
You are correct. The Matrox card does not support the 
GL_ARB_texture_env_combine extension.

> 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.
> 
Hmmm. (Let me reiterate my earlier caveat: I don't know a lot about GL 
but...) I would think quite a few 'older' video cards are not going to 
support the GL_ARB_texture_env_combine extension. Is it a necessary 
design decision that these cards suffer from slow text rendering in GL? 
This seems to set the bar rather high for using cairo with glitz.

When creating the glitz surface we use this call to get the format:
     unsigned long format_options = GLITZ_FORMAT_OPTION_ONSCREEN_MASK;
	format_options |= GLITZ_FORMAT_OPTION_NO_MULTISAMPLE_MASK;

     glitz_format_t *format =
          glitz_glx_find_standard_format (dpy,
                                          DefaultScreen (dpy),
                                          format_options,
                                          GLITZ_STANDARD_RGB24);
Given this call, why would we be using alpha textures? I can see why you 
would want to have it in the general case but shouldn't you be able to 
do without it in particular instances? Or am I confusing two different 
things here?

> 
> 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.
> 
Again, won't this be a limiting restriction for older hardware?

> 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.
This is excellent information for us to know. Thank you.

charlie