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

[Bill Spitzak]

On 10/03/2014 08:21 AM, Derek Foreman wrote:

> One thing that's bugging me... I think normally a 90 degree rotation
> doesn't require LINEAR filtering - doesn't this change if device pixels
> aren't square?

If the device pixels are not square then a 90 degree rotation that 
preserves shape will not result in integers in the scale part of the 
matrix. So you will still get all the information you need out of the 
matrix.

Nearest filtering requires that all the entries be integers, that the 
last row be 0, 0, 1, and that the top left have two zeros on a diagonal. 
If you want scales larger than 1 to be not be "blocky" but instead use 
smooth interpolation, nearest filtering will also require the top-left 
numbers to all be 0, 1, or -1.

> I'm curious as to how zero a zero has to be (in the d[0],d[5] or
> d[4],d[1] positions, depending on rotation) or how 1 a 1 has to be,
> since we're using floats.  testing for equality may miss cases where a
> screen transform and a surface transform cancel eachother out "almost"
> completely.  The tolerances of the zero seem to me to depend on the size
> of the surface.

Rounding does appear to be useful. For instance if you use 
sinf/cosf(M_PI_2) to set a 90 degree rotation you will not get numbers 
equal to 0.0 and 1.0.

The easiest way to figure out the matrix is that all columns before the 
last are the transforms of the x,y,z axis. The last column is the 
location of the origin.

       |   ^      ^      ^     ^   |
       |x-axis y-axis z-axis origin|
       |   v      v      v     v   |
       |   0      0      0     1   |

I think in normal use if there is a projection the bottom row is changed 
but the axis and origin are still correct, they are in camera space 
where the camera is at 0,0,0 and it is looking along the -z axis.