> 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 _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
