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

[Pekka Paalanen]

On Thu, 02 Oct 2014 12:15:35 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On 10/02/2014 12:37 AM, Pekka Paalanen wrote:

> > 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

You must have missed our code, we already have some flags:
http://cgit.freedesktop.org/wayland/weston/tree/shared/matrix.h#n30

However, I'm not exactly sure they are the most useful form. When they
were discussed, I think I tried to propose something like identity,
scaled (no rotation), similarity (scale + rotation), affine,
projective, but IIRC that was met with some resistance.

Separating 90-deg rotations from arbitary rotations could be useful,
too.

Again, should have probably just looked at what Pixman does. The flags
can be easily changed if there is a better scheme.

The primary use for the flags is to optimize matrix classification:
whether a fast-path like hardware overlays can be used. That is,
exactly the analysis in renderers/backends you mentioned. What we are
trying to simplify here is to provide renderers and backends a single
matrix for the complete transformation from buffer pixels to output
pixels, so everything related to computing the total transformation is
shared in weston core, and then backends just analyze this one matrix.

We could be using the flags to optimize matrix ops, but we don't so
far. No-one has seen the need to optimize our matrix ops. I suspect
very few people if any have even profiled Weston.

If someone proposes patches to optimize them, I will a) require test
additions to make sure they work right, and b) ask for profiling
results to justify the code.


Thanks,
pq