[Xr] Re: Clipping to rectangles

Bill Spitzak spitzak at d2.com
Wed Jun 4 18:46:41 PDT 2003


On Wednesday 04 June 2003 12:22 pm, Owen Taylor wrote:

>  - 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 realize this. This is probably a mistake in Xr as it makes it 
impossible for a toolkit to use the clipping to restrict drawing to the area 
of it's widgets. I would certainly add a method of intersecting the current 
path with the clip to get a new clip, and would even go as far as removing 
the current call and having XrRestore and XrSetDrawable be the only calls 
that can make the clipping path be larger than it currently is.

> As things stand right now, I'd probably just do
> operations on a target surface the size of the bounding
> box, and do the clip when copying from the backing store (*)
> but being able to tell Xr about the real clip region
> would be nice from a performance point of view.

That would require an entire backing store for every widget, and an interface 
would still be necessary to define the clip when copying from the backing 
store. I don't think people will like this solution much.

> (*) This brings back up the question of the problem
>     of "clipped" not meaning "untouched" with the
>     current semantics.

It is easiest to explain clipping as a mask that all images being painted are 
multipled by. The problem is that some of the compositing operators will 
change the zero area in the final composite. This leads to much more complex 
definitions of clipping, all of which have disadvantages, such as making it 
impossible to access the "sums to 1" OpenGL type compositing when clipping. 
It also makes the obvious implementations of clipping (such as what Xr does 
now) impossible.

I think an acceptable alternative solution would be to instead remove from Xr 
all the Porter-Duff compositing operators where zero in the foreground alpha 
changes the result. This may sound really daring, but I think in real-world 
examples those operators are not used. It would also remove a lot of code 
from Xr. The few cases where it is needed can be handled by an "invert path" 
operator that flips the inside and outside of the path so the outside is 
filled.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com




More information about the cairo mailing list