chris at chris-wilson.co.uk
Mon Oct 22 15:00:53 PDT 2007
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:
> > 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.
> 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.
More information about the cairo