[cairo] Performance issue with cairo-1.10

[Holger Hans Peter Freyther]

On 11/03/2010 12:06 AM, Siarhei Siamashka wrote:


> There seem to be 3 cases in _draw_image_surface, depending on what format
> you use for cairo_image_surface_create in your example:
> 
> 1. CAIRO_FORMAT_RGB24
> 
> In this case 'surface' is using 16bpp format. There is something wrong with not 
> using pixman for conversion (pixman is only used if _pixman_format_to_masks 
> returned error). So it ends up running a naive C loop. If it actually used
> pixman, I would assume that the performance might be comparable to case (2).

Yes, as I said the value for 'cairo_content_t' is the same for the surface
with 16 bit depth and the cairo_image_surface created with CAIRO_FORMAT_RGB24
but there is no 'fast' path in cairo to paint the CAIRO_FORMAT_RGB24 image
surface onto a 16bit depth xlib surface.

My argument would be, cairo should not create a 16bit surface when it needs to
paint a RGB24 image surface.


> 2. CAIRO_FORMAT_ARGB32

yes..

> 
> 3. CAIRO_FORMAT_RGB16_565
> 
> In this case both 'surface' and your image are using 16bpp format. Everything 
> is fast, or at least should be fast.

yes.

The problem is that the application need to detect which CAIRO_FORMAT without
alpha to use for the image surface. Do you happen to know if GDK is somehow
exporting the cairo_format_t for its cairo drawable?

E.g. if I make my image surfaces RGB16_565, I am pretty sure I will start
going through the slow path on desktop and other modern systems.

The example from the previous mail shows that cairo 1.8 was going through the
fast path (and letting the xserver drive pixman for color conversion) but now
with cairo-1.10 it decides to create a xlib-surface that forces a slow path.