I guess this is a very meaningful patch. In GTK's uses, fast path can improve more than expected since it heavily depends on X.org's drawing path. In particular, mobile phones have a variety of rotation uses cases such as 90, 180, and 270 degrees. Epecially, ARM NEON optimization might significantly help those in mobile industry. I am ready to take a part in this action. Way to go!


Siarhei Siamashka 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
> FAST_PATH_SCALE_1X |
> FAST_PATH_X_UNIT_POSITIVE |
> FAST_PATH_Y_UNIT_ZERO |
> FAST_PATH_MATRIX10_ZERO |
> FAST_PATH_AFFINE_TRANSFORM |
> FAST_PATH_NEAREST_FILTER |
> FAST_PATH_SAMPLES_COVER_CLIP
> 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.



Soren
_______________________________________________
Pixman mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pixman

Reply via email to