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

[Pekka Paalanen]

On Mon, 14 Sep 2015 20:52:18 +0200
soren.sandmann at gmail.com (Søren Sandmann) wrote:

> Ben Avison <bavison at riscosopen.org> writes:
> 
> > It's an odd omission that it doesn't talk about BILINEAR filtering,
> > though. However, having briefly read through the text, even though some
> > of it goes over my head a bit, I'd say it's describing from a strictly
> > mathematical point of view. Discussion of exactly which pixels get loaded
> > from memory in order to reach this mathematical outcome feels outside the
> > scope of that document to me.
> 
> My take on the question is that conceptually the BILINEAR filter works
> by loading four pixels surrounding the sample locations, and then
> convolving them with a 2 x 2 matrix where the entries are determined by
> the fractional part of the sample position. The question then is: How do
> you determine the North-West pixel? And the answer is that you round
> down. The other three pixels are then found by adding 1 to one or both
> of the North-West pixel's coordinates. The CONVOLUTION filter works this way
> too, except the matrix may be bigger than 2x2 and is given explicitly
> rather than implicitly.

Hi,

it would have been really nice to have this explanation in rounding.txt.

I did think about a 2x2 matrix in connection to CONVOLUTION, but I
couldn't quickly formulate it in a way that it would have produced what
the code does. Particularly, the choice of the matrix contents was my
problem, because it didn't occur to me that they are per bilinear
sample (destination pixel) and not constants.

How's my version of it, or should I re-write it based on CONVOLUTION?

To me, using CONVOLUTION seems like a detour. I don't think computing a
discrete convolution usually involves computing a different matrix for
each destination pixel. I think that would involve a lot more
explaining on how convolution in this case doesn't use a constant
matrix.

> It is important to note that a pixman image is not undefined outside its
> borders because the repeat mode always says what happens if you ask for
> such a sample.
> 
> Now, of course, if the sample position is exactly on top of a pixel,
> some of the weights in the matrix will be zero and so a possible
> optimization is to eliminate those memory references. But I think this
> should be considered an optimization and not the specification.

Where should we document what COVER_CLIP_BILINEAR means?

It would be pretty convenient to just state in rounding.txt on what
choices Pixman's implementation does, just like is said for NEAREST.

I understand the definition of the flag is a Pixman internal detail,
while the things said about NEAREST so far are actually public API.


Thanks,
pq

> I think this is my basic concern: In my mind BILINEAR_COVER_CLIP says
> "if[1] the filter is BILINEAR, then all pixels required for the
> operation (regardless of weight) are inside the borders of the source
> image". This is useful information for the implementations because it
> means they can elide the border-checking logic.
> 
> A separate possibility is a flag that says "all pixels whose weights are
> non-zero are inside the borders of the source image". Is this useful
> information? It might be, and if so, it could be conveyed through some
> new flag, though I'd echo Siarhei's comment about whether this is
> something that happens in practice.
> 
> 
> Søren
> 
> 
> [1] A subtle, but mostly irrelevant for this discussion, point is that
> the flag can be set even if the filter in question is not actually
> BILINEAR.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20150915/40815934/attachment.sig>