[PATCH] Clarify semantics of clipping

Soeren Sandmann sandmann at daimi.au.dk
Fri May 1 18:13:15 PDT 2009


This patch attempts to clarify how clipping works in Render.

* Explicit clip masks

A client can set an explicit clip mask on a picture, and the current
spec claims that it affects both input and output. That's not true for
transformed pictures or gradients or solid fill pictures, and it's
unclear what it means for repeated pictures.

In the patch I attempt to make it clear that the clip masks are
interpreted *after* repeating and transforming, ie., that repeats and
transforms do not affect the clip.
 
This still is not what the current implementation does, but this
interpretation is easily implementable in the

        pixman_compute_composite_region32()

function that computes the region in destination coordinates affected
by the composite operation.

Fixing this will cause clip masks to start applying to transformed
pictures and to gradients and solid fills. This could be viewed as
breaking backwards compatibility, but I suspect nobody is actually
relying on this traditionally-buggy part of Render.

* Hierarchy clips

Hierarchy clips for sources and masks, to the extent they make any
sense at all, must be affected by transformations, filters and
repeats. This means they cannot be implemented as a preprocessing step
the way client clips and destination clips.

In the software implementation this manifests itself by region lookups
showing up in inner loops, and duplication of entire blocks of code
based on whether there is a clip or not. In hardware implementations,
it means straightforward bilinear texture sampling is no longer
adequate because it too must do region lookups during sampling. One
potential way to implement it would be to make a copy where the
obscured areas are filled with 0, but this is not particularly
efficient.

Finally, for window sources to actually be useful GraphicsExposes must
be generated, and the current implementation don't. A simple
implementation is to just expose the entire destination, but this is
inefficient. A more more effcient implementation requires keeping
track of what pixels are unavailable, which causes region lookup
during sampling to return.

So the patch changes the spec to say that

- for sources and masks, subwindow_mode is ignored and obscured pixels
  (whether by siblings or by inferiors) have undefined values

- GraphicsExposures are never generated

Note that if a working implementation of GraphicsExposures and
clipping shows up, the spec can be compatibly extended to specify
these things again.


Soren




More information about the xorg-devel mailing list