[Xr] Clipping to rectangles
otaylor at redhat.com
Wed Jun 4 13:35:41 PDT 2003
On Wed, 2003-06-04 at 15:53, Carl Worth wrote:
> 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
> > list.
> 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
I remembered doing so, and was just going to quote whatever I said
there, but couldn't find the mail.
I don't have a strong opinion whether separating them from from
the user perspective makes sense; what I care about more is
that the efficiency of the pixregion style is preserved for
what GTK+ is doing.
An intermediate solution would be to have a "clip to rectangles"
call that is equivalent in end results to using a clip path
composed of rectangular segments, but that Xr is smarter
I wouldn't be at all surprised if postscript's 'rectclip' operator
short-circuits the general clip path case.
> > - 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.
In some cases, it may make sense to set a clip region of the
destination surface to a region bounding the clip path but
that is not exactly the clip path; though you have to be
a little careful about bounding the complexity of the path
> > - 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
Ah, OK, "appends" was unclear to me... I didn't understand it to
More information about the cairo