[Xr] Clipping to rectangles
cworth at east.isi.edu
Wed Jun 4 12:53:00 PDT 2003
On Jun 4, Owen Taylor wrote:
> Typical an entire drawing operation in GTK+ is clipped
> to the expose area that is being redrawn, an arbitrary rectangle
I think it may make sense to support two separate notions of
clipping. The first, (XrClip), is a PostScript-like clip defined with
a path, (with the conventional user space -> device space
The other notion is to restrict drawing operations on a particular
surface to region defined by a set of whole device pixels, (stored as
a list of device-space rectangles). Xr already has a little library,
(libPixRegion), for constructing such pixel regions, and it very
nearly has a function (XrSurfaceSetClipRegion) for applying that
region to a surface.
It's not entirely clear to me if these two separate notions should be
exported to the user. (I believe Owen requested it specifically at one
> - The efficiency question, as has been discussed here.
It probably wouldn't be too hard to get XrClip to notice the
conditions under which it could temporarily alter the clip region of
the destination surface rather than doing the extra compositing that
it does in the general case.
> - The Xr clip operator, at least as Carl described
> it initially, differs significantly from the
> Postscript clip operator in that it replaces
> the clip path, instead of intersecting with the
> clip path.
I did not intend to describe it this way. I believe I said it appends
the current path to the current clip path. This means the region
inside the new clip path is the intersection of the regions inside the
current clip path and the current path.
The intention is for the semantics of XrClip to match the PostScript
> (*) This brings back up the question of the problem
> of "clipped" not meaning "untouched" with the
> current semantics.
Yes, this is still an open issue.
USC Information Sciences Institute cworth at isi.edu
More information about the cairo