[cairo] Transform optimization
jeff at infidigm.net
Fri Nov 7 09:33:21 PST 2008
On Fri, Nov 07, 2008 at 03:15:56AM +0100, Soeren Sandmann wrote:
> Hi André,
> > I'm searching for some opportunities to optimize other pieces of code,
> > and I'm working now with the transformation code. Checking with VTune,
> > I saw that a great hotspot at fetching the pixel call (do_fetch). So I
> > tried to reduce this fetch, checking if I just read this pixel before,
> > and works well for magnifying (about 2x in Core2 and 1.66x in
> > Turion).
> It is certainly true that do_fetch() is a hotspot, and the main reason
> is that it does an indirect call to the format specific pixel
> fetcher. For bilinear filtering, this means four indirect functions
> calls per pixel.
> Working around this problem with caching will help a bit, especially
> for upscaling, but as Jeff notes, do_fetch() should just be a memory
> read in the common case.
> The better fix here is to write a bilinear fetcher that special cases
> for the common case of
> - image has format x8r8g8b8 or a8r8g8b8
> - the transformation is affine
> - there is no source clip
> Such a fetcher wouldn't have to do any indirect function calls and it
> could avoid the check for perspective transformations altogether.
Yep. I agree that this is the prefered way to go.
> Another specialization for pure scaling transformations could take
> advantage of coherence by caching the interpolation between the two
> pixels on the last right edge.
> The "fetch-refactor" branch of this repository:
> contains a refactoring of some of the transformation code that gets
> rid of a lot of gratuitous code duplication. It will likely be useful
> as a starting point for optimizing the transformation code.
> I will probably merge that branch soon unless someone tells me that it
> would interfere with what they are working on.
This looks good to me, though I'm curious: what kind of effect does it
have on performance?
More information about the cairo