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!
<br>
<br>
<br> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
<br>
<br>> And additional somewhat related observation. Simple translate transforms are
<br>> currently taking nearest scaling fast paths, which is definitely a lot better
<br>> than general path. But we surely can do better. Combination of flags
<br>>     FAST_PATH_SCALE_1X |
<br>>     FAST_PATH_X_UNIT_POSITIVE  |
<br>>     FAST_PATH_Y_UNIT_ZERO |
<br>>     FAST_PATH_MATRIX10_ZERO |
<br>>     FAST_PATH_AFFINE_TRANSFORM |
<br>>     FAST_PATH_NEAREST_FILTER |
<br>>     FAST_PATH_SAMPLES_COVER_CLIP
<br>> could be used to select a simple nonscaled and nonrotated optimized translate
<br>> transform fast paths. Or alternatively translate transforms could be handled in
<br>> a special way by just updating 'src_x'/'src_y' variables. But these flags still
<br>> may be useful for fractional translations with bilinear filter .
<br>
<br>It could be interesting to go the other way too: If all the fast paths
<br>got support for pure translation matrices, then we might be able to
<br>drop the src/mask_x/y variables from the composite functions and just
<br>absorb them into the matrix.
<br>
<br>> What I'm trying to say is that optimizations for transformed compositing 
<br>> operations in pixman seem to be "converging" and starting to cover more
<br>> use cases. And the flags are becoming quite descriptive.
<br>
<br>It may be at some point that the whole flag scheme stops working so
<br>well. For example, it could be that the flags eventually become so
<br>descriptive that the fast path cache would be filled with small
<br>variations on the same set of flags.
<br>
<br>In practice, that doesn't seem to happen yet, but it's worth keeping
<br>an eye on.
<br>        
<br>> Anyway, unless there are some comments/objections, I'm going to commit this
<br>> patch with initial rotation flags support a few days after pixman 0.20.0 
<br>> release.
<br>
<br>The patch looks fine to me, though generally I'd prefer to have the
<br>flags pushed at the same time as the code that uses them, just to
<br>avoid a situation where the first part of something is pushed, but the
<br>rest of never happens.
<br>
<br>> +                else
<br>> +                if (image->common.transform->matrix[0][1] ==  pixman_fixed_1 &&
<br>                ^
<br>                These should be on the same line.
<br>
<br>
<br>
<br>Soren
<br>

<!-- __Hanmail-sig-Start__ -->

<!-- __Hanmail-sig-End__ -->

 
<img src="http://wwl358.hanmail.net:4280/@from=jcybha&rcpt=pixman%40lists%2Efreedesktop%2Eorg&msgid=%3C20101030212015%2EHM%2Ez000000000Glqtn%40jcybha%2Ewwl358%2Ehanmail%2Enet%3E">