[Pixman] [PATCH v14 12/22] pixman-filter: fix subsample_bits == 0

[Søren Sandmann]

On Mon, Apr 11, 2016 at 2:43 PM, Bill Spitzak <spitzak at gmail.com> wrote:


> I feel this can be fixed. It is already correct for subsample_bits==0.
> Since both the filter generator and filtering code would be changed in the
> same version, only programs that generate their own filters would actually
> be incompatible. And as you point out the error is very tiny for large
> numbers of subsamples, and Cairo is already using an excessively large
> number of subsamples (likely because I was trying to remove the difference
> between identity filters and nearest filtering, and did not realize this
> was the underlying problem).
>

It is technically an ABI break, and cairo 1.14 did ship with a
copied-and-pasted filter generator that assumes the current subpixel
positioning.

But yeah, maybe we can just ignore that, if we make sure a there is a cairo
1.14.x update that uses pixman_filter_create_separate_convolution() instead
of the copied-and-pasted filter generator.

Other than that, the fix should be straight-forward enough.


Søren


On Sun, Apr 10, 2016 at 10:01 PM, Søren Sandmann <soren.sandmann at gmail.com>
wrote:

>
> It does look like there is something really wrong. I compared and (except
>> for the subsample_bits==0 case) my version produces the same output as the
>> current git head.
>>
>> I think your intention is that there is a sample at offset=0 whether the
>> filter width is even or odd. However (except when subsample_bits==0) the
>> filter generator makes a symmetric filter for even sizes, with two equal
>> samples around the maximum center value. If a sample was at offset==0 then
>> it would be unique and larger than all the other samples.
>>
>
> The root of this confusion is probably that when subsample_bits = k, the
> subpixel positions used are:
>
>     0.5 / 2^k, 1.5 / 2^k, ..., (2^k-0.5)/2^k
>
> For example, for subsample_bits = 2:
>
>     0.125, 0.375, 0.625, 0.875
>
> and for subsample_bits = 0:
>
>     0.5
>
> That is, they are regularly spaced, but centered within the pixel. When
> there is an even number of them, this means there will not be a filter
> position at 0.5, and therefore no sample at offset 0. And the only case
> where number of subpixel locations is odd, is when subsample_bits = 0.
>
> I'm pretty sure that the existing code gets the filter generation right
> for these subpixel positions.
>
>
> [ You can argue that it would be better to use the sampling positions
>
>     0, 0.25, 0.5, 0.75
>
> for subsample_bits = 2, as Owen did here:
>
>     https://lists.cairographics.org/archives/cairo/2014-March/025105.html
>
> and I agree that that would have been better. ]
>
>
> Søren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pixman/attachments/20160411/d5615c2a/attachment.html>