[cairo] XShm

[Chris Wilson]

Behdad Esfahbod (behdad at behdad.org) said: 
> On Mon, 2007-10-22 at 16:04 -0400, Chris Wilson wrote:
> > After spending a short time tuning, the results are still quite mixed:
[snip]
> > But better than the initial 20x slowdown for text with the paranoid
> > XSync'ing.
> 
> Good.  Any idea how to "fix" the slowdowns?  Maybe just bypassing Xshm
> stuff for small images is all you need?

Argh! I'm been chasing the Ghost in the Machine again. Reran cairo-perf
with fresh caches and hit the 17x text slowdown. Ignoring the
requirement to XSync and the slowdown is only 1.5x for some text
benchmarks with a boost of up to 8x for others. Double argh!
Can people run cairo-perf and report results (preferably stable!) for
their hardware? Thanks.

[snip, kudos to Company for the name ;-]

> > 2) cairo_surface_acquire_image()/cairo_surface_release_image() - Vlad's
> > suggestion for a convenient API to directly manipulate the bits
> > representing a raster surface (or failing that degrade appropriately to
> > pulling and pushing the pixels). Having experimented in using this API
> > with swfdec, it does provide an easier method for loading raw data into
> > Pixmaps.
> 
> I'm still not convinced that we need to expose these, but I need to
> first check the patch...  If we can get an API more like the
> push/pop_group, that may help.
 
[snip]
 
> So, hopefully clipping helps allocating a smaller image, right?

Taking the cairo_push_group()|pop_group() approach, then yes clipping
should affect the image returned. With the cairo_surface_acquire_image()
approach it makes less sense due to the cairo_t bypass - the application
can't directly control the clip on the surface, so it would not expect
it to affect the returned image.
--
Chris Wilson