[Xr] Clipping to rectangles

[Owen Taylor]

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
> transformation).
> 
> 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
> point).

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
about optimizing.

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
here.

>  >  - 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
> semantics.

Ah, OK, "appends" was unclear to me... I didn't understand it to
mean intersection.

Regards,
                                               Owen