[Pixman] Benchmarked: [PATCH 1/4] Change conditions for setting FAST_PATH_SAMPLES_COVER_CLIP flags

[Bill Spitzak]

On Wed, Sep 16, 2015 at 7:30 AM, Ben Avison <bavison at riscosopen.org> wrote:

Just by thinking things through, I realised that we would regularly fail
> to hit COVER paths if Pixman's caller set the scale factors such that the
> centre of the outermost destination pixels aligned with the centre of the
> outermost source pixels. There has been some argument about whether this
> is representative of how Pixman should be used. I happen to think this is
> a perfectly reasonable thing to expect Pixman to support, but there are
> other models you can follow, notably setting the scale factors such that
> the outer edges of the outermost destination pixels align to the outer
> edges of the outermost source pixels. If the Cairo traces are using this
> latter model, then it's understandable if you aren't hitting the edge
> case that I'm concerned about very often.
>

There are currently very good reasons for clients to use the first model:
it is a method of removing undesirable "fuzzy edges" from zoomed-in images.

The alternative of scaling the outer edge, while not hitting this fast
path, will not hit the other fast path either! (the other fast path is the
one that allows a zero-weighted pixel at one end to be read from the image).

Therefore I believe there is actual usage of this new fast path, while
there is almost zero usage of the old fast path. This is the main reason I
think the current flag should be removed, and a new one indicating that all
the non-zero samples are inside the image, added. This second one will
actually be used by real code.

NOTE: the method of scaling the centers of the pixels is generally wrong.
The math is wonky: does scaling an image by 2 produce a 2*w-1 image, or
does it spread the pixels slightly more than 2 apart? Programs are going to
disagree. And you have to alter the math as soon as the scale goes below 1
or you will get fuzzy edges again. And lots of code are going to get
coordinates in the resulting image wrong, resulting in annoying problems
like overlaid lines not lining up or shifting their alignment from one side
to another.

I very much believe Cairo should change how CAIRO_EXTEND_NONE is done. It
should instead mean that the path is intersected with a quadrilateral that
is the transform of the outer edge of the source, then drawing as though
using CAIRO_EXTEND_REPEAT. This is what most users of scaling expect, and
anybody wanting the previous effect can get it by adding a black pixel to
the outer edge of their source surface.

Now it is true that this result can be achieved with Cairo right now. The
reason for making this the default is because non-experts are unlikely to
figure this out. Currently filling a path equal to the source boundary
results in a double-mulitplication of the edge pixels, a subtle error that
can be very frustrating when graphics gets more complex. Making this error
not happen by default would be very helpful. I also believe making this the
default will result in faster implementations, as EXTEND_REPEAT fast paths
can be used, and this is often directly supported by graphics hardware.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20150918/2020d86f/attachment.html>