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

Bill Spitzak spitzak at gmail.com
Fri Oct 3 13:04:29 PDT 2014

```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,d or
> d,d 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.
```