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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
