# [Xr] Re: Rectangle operators

Bill Spitzak spitzak at d2.com
Wed Jun 4 18:25:10 PDT 2003

```On Wednesday 04 June 2003 12:57 pm, Carl Worth wrote:
> On Jun 4, Bill Spitzak wrote:
>  > XrFillRectangle(xrs,x,y,r,t)
>  > XrClipToRectangle(xrs,x,y,r,t)
>  > XrClipOutRectangle(xrs,x,y,r,t)
>
> I don't see why new functions are needed in Xr for these if they are
> simply defined in terms of combinations of existing Xr functions.
>
> It seems that Xr should still be able to make the right cases fast
> without needing specialized Fill and Clip functions. (Note that Xr
> does already have a special function for adding a rectangle to a
> path).

I'm trying to avoid the overhead of Xr detecting these cases. I believe that
in about 96.7% of the cases that would be sped up the user is drawing exactly
one rectangle. Using Xr paths requires a sequence of 7 calls (newpath,
moveto, 3 lineto's, closepath, fill) plus the overhead of Xr actually
recognizing that a rectangle was drawn, this seems unreasonable to me.

However a possibly better solution than my proposal is somewhat in-between.
Add only a single call that adds a rectangle to the current path. It is
equivalent to moveto, 3 lineto's, and a closepath. If a path is constructed
only by calling this then a different (faster) method is used to fill or clip
it. In this case only 3 calls are used to fill a rectangle and the slow part
of detection is removed from Xr. This would make it possible to accelerate
other actions like XrStroke, without adding calls. It also adds support for
accelerating lists of rectangles.

>  > If Xr has some way of enumerating the current clippath or turning it
>  > into a path, it may be best to say that whether this returned path
>  > includes the results of these rectangles is undefined.
>
> And semantic confusion such as this is an argument for not including
> the functions.

I was using the same argument for saying that no function should be included
for enumerating the current clip.

spitzak at d2.com

```