[cairo] Performance issue with cairo-1.10

[Siarhei Siamashka]

On Wednesday 03 November 2010 09:44:44 Holger Hans Peter Freyther wrote:
> 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.

Why not? By rendering in non-native RGB24 format in the first place, you either
way end up doing conversion to 16bpp format. Let's compare two cases:

1. copy via XPutImage RGB24 -> RGB24, convert RGB24 -> 16bpp
2. convert RGB24 -> 16bpp, copy via XPutImage 16bpp -> 16bpp 

The second one is going to be faster, because it moves less data around.  And
the final result should be the same.

The important thing is to do this RGB24 -> 16bpp conversion efficiently.

> 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?

Maybe using something like the following (untested) code can help?

if (gdk_visual_get_system()->depth == 16) {
	use 	CAIRO_FORMAT_RGB16_565
} else {
	use CAIRO_FORMAT_RGB24
}

> 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.

IMHO just the slow path should be eliminated. There is no reason to do
x8r8g8b8 -> r5g6b5 conversion so slow. The same naturally applies to
r5g6b5 -> x8r8g8b8 conversion too.

BTW, on ARM devices, x8r8g8b8 -> r5g6b5 conversion should run faster than
x8r8g8b8 -> x8r8g8b8 copy if implemented right.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.cairographics.org/archives/cairo/attachments/20101104/5acdd254/attachment.pgp>