[Pixman] [PATCH 1/4] bits: Implement PAD support in the simple fetcher

[Søren Sandmann]

Ben Avison <bavison at riscosopen.org> writes:

> On Wed, 30 Jan 2013 19:34:58 -0000, Søren Sandmann <sandmann at cs.au.dk> wrote:
>> It's simply that the speedup you got:
>>
>>     SNB i5-2500s: firefox-chalkboard  25.9s -> 19.6s: 1.32x speedup
>>
>> is rather large for a change that doesn't even introduce a fast path or
>> use SIMD. That suggests either that something dumb is going on in pixman
>> or in the benchmark, or that we want SIMD variants of this operation.
>
> By chance, I happened to be looking at this today. I'm finding a whopping
> 15% of the runtime for the whole of cairo-perf-trace is in a single type
> of composite operation in firefox-chalkboard, and it's an over_8888_8888
> which can't be matched by STD_FAST_PATH, SIMPLE_NEAREST_FAST_PATH or
> SIMPLE_BILINEAR_FAST_PATH. STD_FAST_PATH fails because
> FAST_PATH_SAMPLES_COVER_CLIP_NEAREST isn't set in the source flags, and
> SIMPLE_NEAREST_FAST_PATH fails because FAST_PATH_SCALE_TRANSFORM isn't
> set. (If you're curious, the precise source flags are 0x207ca77.)

COVER_CLIP_NEAREST means "under the assumption that the filter is
NEAREST, the clip region of the composite operation will be entirely
within the pixel grid of the image so that there isn't actually any need
for doing repeat calculations". It is supposed to be set by
analyze_extents() in pixman.c. All the standard fast paths rely on this
flag in order to assume that they can just read the source without
checking the bounds.

If the flag isn't set, that means the source image is smaller than the
composite area in the destination (unless analyze_extents() is
buggy).

> Obviously this means that in this case, we're not getting the benefits of
> any platform-specific fast paths. Perhaps what we need is a "pad"
> equivalent of fast_composite_tiled_repeat()?

This might be a good idea, though it's still worth finding out what is
causing an untransformed image with PAD repeat to be drawn without a
mask onto a destination bigger than source image. Either the resulting
stripes are desirable for some reason, or Firefox should be more careful
about clipping to the source image.


Søren