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

[Derek Foreman]

On 02/10/14 02:15 PM, Bill Spitzak wrote:
> On 10/02/2014 12:37 AM, Pekka Paalanen wrote:
>> On Wed, 1 Oct 2014 18:09:32 -0700
>> Jason Ekstrand <jason at jlekstrand.net> wrote:
> 
>>> (do we use "bool" in weston?  Maybe just return int).  We may need
>>> both x
>>> and y scales and it may be useful to get those as floats.  I'm not
>>> sure on
>>> that.  Pekka, what would the RPi backend use?
> 
> It looks like most of the code uses <stdbool.h>, "bool", and "true" and
> "false". However I also found a lot of instances of TRUE, FALSE,
> EGL_TRUE, EGL_FALSE, and using integer and 1 and 0 as return values.
> 
>> Futhermore, if you wanted to cache the buffer-to-output matrix, you
>> would end up with number_of_views * number_of_outputs matrices to be
>> cached. The buffer-to-global per-view matrix might not change too
>> often, but we tend to paint outputs in turns, which means doing just
>> per-view cached total matrix is a waste.
>>
>> So you might have buffer-to-surface matrix in weston_surface, then
>> buffer-to-global matrix cached in weston_view. I'm not sure it makes
>> sense to cache buffer-to-output anywhere.
> 
> Actually most backends are going to analyze the matrix anyway, so using
> this to short-circuit filtering is not that useful.
> 
> But a set of flags attached to the matrix can help in speeding up
> multiplication. This would avoid having to cache all the matrices and
> would make creating them faster in normal cases. The flags should be
> designed so when you multiply the matrix you can bitwise and the flags.
> Something like this:
> 
> AFFINE: last row is 0,0,?,1
> NO_SKEW: a00*a01+a10*a11 ~= 0
> NO_SCALE: a00^2+a01^2 ~= 1 && a10^2+a11^2 ~= 1
> ORTHO: a00==a11==0 or a01==a10==0
> NO_ROTATE: a01==a10==0
> NOT_DEGENERATE: a00*a11-a10*a01 != 0
> NO_MIRROR: a00,a01,a10,a11 are all >= 0
> INT_SCALE: a00,a01,a10,a11 are all integers
> INT_TRANSLATE: a03 and a13 are integers
> IDENTITY: identity matrix

Interesting - but I'm not sure matrix multiplication is slowing us down
enough to be worth optimizing it that heavily?