[cairo] [PATCH 0/2] Update pixman reference images

[Bill Spitzak]

On 10/29/2014 01:55 PM, Bryce Harrington wrote:
> On Fri, Oct 10, 2014 at 12:30:29PM -0700, Bill Spitzak wrote:
>> On 10/10/2014 11:19 AM, Bryce Harrington wrote:
>>
>>> Will do.  All of these looked fine.  The 96:24 BEST cases looked
>>> legitimately broken but I think that needs separate investigation.
>>
>> output/*best-24.*.argb32 are showing some transparency leaking in
>> from the edges in my examples. Both the argb32 and rgb24 versions
>> are showing ringing around all the color transitions, but this is
>> going to happen with such a high-contrast source image.
>>
>> The good filter does not produce this ringing.
>
> Yeah it sounds like ringing is an inevitable trade-off here.

Actually most of the artifacts seem to be blurring, not ringing. This is 
however the definition of the cubic filter and I am pretty certain is 
correct.

The good filter should produce blur as well, except the scale is exactly 
1/integer. A scale that is not an integer would be a better test.

The reason the "best" filter is better than "good" is that the amount of 
blur is consistent at different scales and fractional translations, even 
though the "good" filter can produce a very sharp image at some positions.

> So, should we just mark these tests xfail, or is it worth exploring if
> we could do better in these corner cases?  If the latter, perhaps we
> need a fairer test?

A solution might be to use a lower-contrast image. You still want sharp 
edges, but the difference in brightness between adjacent pixels should 
only be about 10x the threshold for the image comparison program, this 
would make differences in blur or ringing pass the tests.

>> I think these results are correct though eog likes to show the
>> transparent leakage as a white edge. If you change it to composite
>> atop black the edge disappears.
>
> I've been using xzgv to view the images, fwiw.

The transparency leaking in the "best + argb32" image is a concern, but 
I believe it is correct according to Cairo's design and description of 
CAIRO_EXTEND_NONE. The lack of leaking transparency in the "best + 
rgb24" image may be a mistake. There should also be leaking transparency 
in the "good" examples if the scale was not an integer.

These artifacts are a problem. They vary depending on whether the scale 
exactly divides the image size. They are also completely unexpected by 
users of Cairo, and subtle enough to not be noticed immediately, 
resulting in artifacts in finished software.

I believe the correct solution is to change Cairo's definition of 
CAIRO_EXTEND_NONE. It would actually mean that CAIRO_EXTEND_PAD is done, 
except any composite using an image source would also act like the 
transformation of the source area is a clipping path. Besides removing 
this artifact, this also produces sharp edges for zoomed-in images 
(which many users expect) and it is much faster to to implement on 
modern hardware designed for OpenGL.

>> Attached are my results in case you are getting something different.
>
> I've unfortunately cleaned up my previous results but I seem to recall
> seeing something a bit more severe.  I'll doublecheck it after I've
> finished the next weekly test run, tomorrow probably.

Yes I think we need to find out if we are getting the same images.