[Pixman] Issue observed with Pixman 0.28.0 series

[Søren Sandmann]

> I have observed few issues with the rendercheck utility (from X) with the
> "triangles" use case
> for operators src, clear, In , out.
>
> Using a simple usecase: (with "Src" render operator)
> ./rendercheck -f r8g8b8 (or a8r8g8b8) -t triangles -o Src  --minimalrendering.
>
> I am not an expert here, but what I know is, that this test case basically
> composites 2 triangles (red in color)
> on a white background and then reads back the value for crosschecking. The test
> gets the desired red values
> inside the triangles but outside the triangles it gets  black (should be white,
> as the background window is white).
>
> Debugging into the pixman library, I noticed the pixman_composite_trapezoids().
> In that, the get_trap_extents() (newly added) is setting the box region (x1,
> x2, y1, y2) to the whole "dest" width & height,
> as opposed to setting only the region of interest (trapezoids). This is mainly
> because of the  zero_src_has_no_effect[] array,
> making the function to set these values.
> This causes the the background to go black with a red block (trapezoids) on
> top. (as observed on display)
>
> Is this a bug with the way rendercheck (or X)  is using the new pixman or the
> bug is in pixman itself?
> This issue was not observed with the previous versions.

I believe the new behavior you are seeing is correct. The Source
operator in Porter/Duff is defined to replace the destination and so it
is expected that no traces of the white background remains. Contrast
with the Over operator, where the trapezoids are overlaid on the white
backgroudn.

The difference in behavior is whether compositing for the Trapezoids and
Triangles requests is clipped to the bounding box of the list of
trapezoids/triangles. In the old version, they were, in the new they are
not.

In my view, the current behavior is the correct one since clipping
really shouldn't be based on the list of trapezoids and shapes. For
example, if we were to reinstate the clipping behavior, what should
happen if one of the trapezoids is empty? Should that still affect the
clip region?

Instead, the clipping is better considered an optimization that is only
correct for certain operator. For many operators (the ones listed as
TRUE in the zero_src_as_no_effect[] array), they are the same, but for
others they are not, and so the clipping that still takes place is not
so much a region-of-interest as it is a region-where-the-destination-
may-be-affected.


Søren