<div dir="ltr">On Wed, Sep 16, 2015 at 7:30 AM, Ben Avison <span dir="ltr"><<a href="mailto:bavison@riscosopen.org" target="_blank">bavison@riscosopen.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just by thinking things through, I realised that we would regularly fail<br>
to hit COVER paths if Pixman's caller set the scale factors such that the<br>
centre of the outermost destination pixels aligned with the centre of the<br>
outermost source pixels. There has been some argument about whether this<br>
is representative of how Pixman should be used. I happen to think this is<br>
a perfectly reasonable thing to expect Pixman to support, but there are<br>
other models you can follow, notably setting the scale factors such that<br>
the outer edges of the outermost destination pixels align to the outer<br>
edges of the outermost source pixels. If the Cairo traces are using this<br>
latter model, then it's understandable if you aren't hitting the edge<br>
case that I'm concerned about very often.<br></blockquote><div><br></div><div>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.<br><br></div><div>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).<br><br>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.<br><br></div><div>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.<br><br></div><div>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.<br><br>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.<br><br></div></div></div></div>