[cairo] XShm

[Chris Wilson]

BJörn Lindqvist (bjourne at gmail.com) said: 
> I'm not sure if my test program (see attachment) is totally accurate.
> But here is the results with your patch applied and without. Without
> patch (best result):
> 
>     total 5651,23 ms, per loop 5,65
> 
> And with patch applied (best result):
> 
>     total 2045,10 ms, per loop 2,05

That result looks in line with my optimistic interpretation of
cairo-perf's output. Your benchmark is definitely triggering an upload
of the image pattern to the server on each loop. I've the perfect patch
for micro-benchmarks like this... (The patch caches the pixmap generated
to hold the image pattern and re-uses it unless the image has changed -
effectively converting the cairo_image_surface_create() into a
cairo_surface_create_similar()).
 
> Which is totally great and faster than gdk_draw_pixbuf(). :) But there
> seem to be no fallback in case Cairo is compiled with shm and the X
> server doesn't support it. cairo_image_surface_create_for_target()
> calls _cairo_xlib_surface_create_image_surface() which won't fall back
> on cairo_image_surface_create() if shm isn't available (but compiled
> in).

Unless I made a mistake, _cairo_xlib_surface_create_image_surface()
should return CAIRO_INT_STATUS_UNSUPPORTED if it fails to create the
surface due to lack of support from the Xserver or system, i.e it checks
the display->use_shm and clears the flag if it encounters an error
whilst trying to set up the shared memory. This should in turn
cause its callers to fall back to ordinary images.
 
> Only drawback I can see is that you need to use
> cairo_image_surface_create_for_target() to get shm goodness. Is there
> no way to get around that? AFAIK, GDK doesn't need such a function to
> draw pixbufs using shm.

Yes, I agree that that is a limitation with this design. AIUI,
GDK composites its pixbufs via a XShmPixmap tiling the operation to fit,
which allows it to avoid the XPutImage(). A similar mechanism would not
work with cairo as it does not perform the immediate composition of the
image, but uploads it to the backend with one call and then will use it
over a sequence of general operations. I think it is fair to say that
the correct approach is for the application to cache its preferred
images in similar surfaces - which need just as much prior information
about the target backend as the optimized images.
--
Chris Wilson