Owen Taylor <otaylor at redhat.com> writes:
> > However, as soon as a transformation gets applied the Composite operation
> > doesn't get clipped; as far as I can tell, anything pixman fetches outside
> > the bounds of a RepeatNone Picture is black.
> > Are you planning to change pixman to fetch transparent in that case? We
> > implemented our driver to match pixman's current behavior.
>
> [bangs head into wall]
>
> When the implementation doesn't match the spec, the spec wins. Of
> course, unless there is a bug in the spec, but then that needs to be
> agreed upon and fixed *in the spec*
To be fair, the RENDER spec and reality very much disagree with each
other. Here is a non-exhaustive list of problems:
* Repeating images
- The spec makes reference to a "fill_constant" parameter to
CreatePicture, which doesn't exist.
- The spec mentions three options for pixels outside the drawable:
Transparent, Nearest, and Tile. These options are not mentioned
anywhere else, in particular they are not mentioned in the
implementation which uses these repeat options:
None: presumably corresponds to Transparent
Regular: presumably corresponds to Tiling
Pad: presumably corresponds to Nearest
Reflect: presumably corresponds to ?
None of these are described in the spec.
- The Repeat* properties are largely unimplemented, except for
gradients. for normal images, only RepeatNormal is implemented. For
those RepeatPad and RepeatReflect are treated as RepeatNormal.
- For gradients the meaning of the repeat options on the type of
gradient. (Generally, the repeat property applies to a linear
gradient, which is then rotated etc.) This is not described at all.
* Clip Regions
- According to the spec you can associate clip masks with all
pictures, including gradients, but the implementation ignores clip
masks for gradient and solid pictures, and for transformed pictures
I believe.
- The spec says that the repeating algorithm are used for images where
pixels are unavailable, whether they are unavailable because they
are outside the geometry or unavailable due to the window hierarchy.
This is useless. Pixels that are unavailable due to the window
hierarchy should be treated as transparent, and if you make use of
them, a GraphicsExpose should be generated.
Fortunately GraphicsExposes are not implemented, so the current
reality is that using windows as sources can not work unless you
know that the window is not obscured.
- The interaction with repeats and client clip is unclear. What should
happen is probably that everything outside the client clip is
transparent, regardless of repeat pattern, because this allows you
to clip out a shape of a repeating pattern.
Essentially for a repeating picture, the hierarchy clip should be
repeated according to the repeat algorithm; the client clip should
be applied once.
* Overlapping images
The spec doesn't say anything about what happens if the pictures
involved in a composite request overlap.
- The implementation does not support this in general; it is easy to
construct cases where pixels are overwritten before they are later
read.
- It is not clear to me how to implement overlapping drawables
correctly in the presence of transformations, except by first
copying the drawables in question.
- There are existing clients (gtk+) that rely on being able to use the
same drawable as the source and mask. This particular case works in
the implementation as long as there are no transformations involved.
* Gradients
- The spec doesn't say what a conical gradient is.
- There is no pixelation spec for gradients.
- It doesn't say which of the many attributes are valid for gradients
and solid fills.
* ColorTriangles, ColorTrapezoids, QueryDithers, Scale, Transform,
AddGlyphsFromPicture.
None of these requests are implemented. Either they should be, or they
should be deleted from the spec.
- Scale, Transform, and QueryDithers are not mentioned in the spec
at all, but they have BadImplementation implementations.
* Misc:
- Spec says the TRAPEZOID type is deprecated. The Trapezoid request
should also be marked as deprecated then.
- Triangles are not used by anyone
- Alpha maps are not used by anyone.
- Trapezoid rasterization has exact pixelization requirements, but
Carl says the regular grid is both bad looking and difficult to
implement efficiently.
> If you try to implement what you think the current implementation is
> doing, then you just subject your users to another round of buginess as
> things are fixed elsewhere.
Agreed in principle, but as demonstrated above, on several issues the
RENDER spec ranges from wrong to meaningless, so matching the software
implementation is understandable from a pragmatic point of view.
Soren