[Xr] Re: Rectangle operators

[Bill Spitzak]

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