Soeren Sandmann sandmann at daimi.au.dk
Thu Oct 28 17:35:10 PDT 2010

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> And additional somewhat related observation. Simple translate transforms are
> currently taking nearest scaling fast paths, which is definitely a lot better
> than general path. But we surely can do better. Combination of flags
> could be used to select a simple nonscaled and nonrotated optimized translate
> transform fast paths. Or alternatively translate transforms could be handled in
> a special way by just updating 'src_x'/'src_y' variables. But these flags still
> may be useful for fractional translations with bilinear filter .

It could be interesting to go the other way too: If all the fast paths
got support for pure translation matrices, then we might be able to
drop the src/mask_x/y variables from the composite functions and just
absorb them into the matrix.

> What I'm trying to say is that optimizations for transformed compositing 
> operations in pixman seem to be "converging" and starting to cover more
> use cases. And the flags are becoming quite descriptive.

It may be at some point that the whole flag scheme stops working so
well. For example, it could be that the flags eventually become so
descriptive that the fast path cache would be filled with small
variations on the same set of flags.

In practice, that doesn't seem to happen yet, but it's worth keeping
an eye on.
> Anyway, unless there are some comments/objections, I'm going to commit this
> patch with initial rotation flags support a few days after pixman 0.20.0 
> release.

The patch looks fine to me, though generally I'd prefer to have the
flags pushed at the same time as the code that uses them, just to
avoid a situation where the first part of something is pushed, but the
rest of never happens.

> +		else
> +		if (image->common.transform->matrix[0][1] ==  pixman_fixed_1 &&
                These should be on the same line.


More information about the Pixman mailing list