On Mon, Apr 11, 2016 at 2:43 PM, Bill Spitzak <[email protected]> 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 <[email protected]> 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 >
_______________________________________________ Pixman mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/pixman
