[RFC weston 13/16] compositor: Add a function to test if images transformed by a matrix should be bilinearly filtered

[Bill Spitzak]

On 09/30/2014 12:35 PM, Derek Foreman wrote:

> Argh - thanks.  Why isn't Z scale relevant?  I'm worried about making
> assumptions about the transformations these matrices represent and
> having those assumptions violated in the future...  For Z not to matter
> are we assuming projection will always be orthographic?

A projection matrix will have non-zero at [3,2] so that Z contributes to 
the output W. The output Z is only used to set the Z in the depth buffer 
(which I doubt you are using).

>> I recommend instead of checking the rotation to instead look for zeros
>> in the correct locations in the matrix. Matrix must be of the form:
>>
>>   |sx 0  0 tx|
>>   |0  sy 0 ty|
>>   |?  ?  ?  ?|
>>   |0  0  0  1|
>>
>> or
>>
>>   |0  sx 0 tx|
>>   |sy 0  0 ty|
>>   |?  ?  ?  ?|
>>   |0  0  0  1|
>>
>> sx and sy must be ±1, and tx and ty must be integers. The ? can be any
>> value.
>
> That could save us the very expensive matrix decomposition.  I'll try
> this out.  Thanks.
>
> I think this may be better than decomposition for deciding to use video
> planes in compositor-drm as well.

Most code just looks at the matrix for this. The Cairo and Pixman code 
works this way, for instance.

> This is also used for the gl renderer, so I don't think I can count on
> that short circuit there...  Though bilinear vs nearest doesn't have
> anywhere near the same performance impact there.

It may be worthwhile to check the Mesa code to see if it does this sort 
of optimization when using software renderings.

I believe the hardware for bilinear sampling is so fast and optimized 
that you do not save anything by asking for impulse. And I got some 
indications that NVidia's driver does impulse sampling for any samples 
sufficiently close to the center. This was in a floating point image, 
where a math error of about 1/100 of a pixel still produced the expected 
identity image. An equivalent OpenCL program mixed in 1/100 of the 
neighboring pixel, which unfortunately had a very large floating point 
value, so it made the math error visible. But the NVidia driver hid it. 
This seems to indicate some optimization is done somewhere.

> Are you suggesting pixman always be set to use bilinear, and it'll just
> pick nearest automatically when the image transform doesn't require it?

I am currently working on pixman and cairo code, and both of them 
already do tests (ie before any changes I am submitting) for this and 
use nearest filter if possible. You can actually use the default "good" 
filter all the time as it is the same as bilinear (for scaling up).