NORMAL repeat was broken (the optimized function can handle repeat operation
itself and can be screwed up if 'pixman_walk_composite_region' tries to help it
by splitting the work into handling multiple separate areas).
Splitting work into handling different areas does not work right for the
transform case (and it is never used for generic path). The point is that this
splitting only has full pixel precision at the moment, while correct blitting
needs to preserve some fractional part in calculations when moving from one
"tile" to another.
This test script can help in finding regressions in image scaling
fastpath implementations. It uses test program compiled with
and without fastpath code and can compare results of execution
for different pseudorandom compositing operations involving scaling.
Signed-off-by: Søren Sandmann Pedersen <sandmann@redhat.com>
The region validate() code is frequently called by cairo as it is used to
extract regions from the trapezoids for fast-paths through the drawing
code and also for fast-path clipping and the RegionInfo allocation (as
well as the pixman_rect_alloc during the final union) appears as a hot
spot on application memory profiles.
Various pieces of code expect PIXMAN_FORMAT_COLOR (and its less cool older
brother, PICT_FORMAT_COLOR) formats to have ARGB bits, and the YUV formats do
not.
fbCompositeSrcAdd_8000x8000arm() tries to align 'dst' already but must check
'src' too. Otherwise, the next 4-byte copy loop might access an odd 'src' address
causing an alignment trap.
Patch from Enrico Scholz
Add a special case for a source transformation that is only a scale and
preserves rectangular pixels and doesn't rotate the image. Currently, only
SOURCE is special cased, however I plan to do more work in this area as needed.
The biggest advantage the specialization currently has is writing directly to
the destination surface instead of a temporary scanline buffer. However, it is
still pretty unoptimized but I want to keep things simple for now.
