[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