[cairo] Performance issue with cairo-1.10

[Holger Hans Peter Freyther]

Hi all,

one of my applications is consuming a lot more CPU time after upgrading from
cairo-1.8 to cairo-1.10. According to oprofile and manually 'sampling' with
gdb it spends a lot of time in _draw_image_surface and there in the 'slow'
path calling _field_to_8.

My setup is a PXA270, running Xfbdev (tinyX/kdrive) with a native depth of
16bpp. In the demonstration application I am using a GtkDrawingArea, create a
RGB24 image_surface and then try to paint the image on the surface allocated
by GDK (obviously backed by xlib).

My understanding goes so far that the cairo_paint call in the expose_event
will create a new surface and then copy/draw the image surface.

Let me explain where I think stuff is going wrong.

In _cairo_xlib_surface_clone_similar we deal with a
_cairo_surface_is_image(src) and then call _cairo_xlib_surface_create_similar.

Now the xlib surface used by the GDK Window has a xrender_format set and the
depth of it is 16bit and both this surface and the image surface have the same
content.

This means that:
    if ((xrender_format != NULL &&
        _xrender_format_to_content (xrender_format) == content)

will evaluate to true and a xlib_surface with 16bit depth and the visual of
the original GDK surface is used. The call to _draw_image_surface will now try
to draw a 24bpp image to a 16bit surface through the slow path.

The workaround for the application would be to use the ARGB32 format to make
the content not match and then the 24bpp can be copied using the fast path. To
make this a regression cairo-1.8 is using a 24bpp surface to copy the image
surface.

Was this change intentional? What options exist to find a fix in cairo itself?

holger
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.c
URL: <http://lists.cairographics.org/archives/cairo/attachments/20101031/09d846ee/attachment.txt>