[Xr] Can the xrs argument be removed?

[Carl Worth]

On May 22, Bill Spitzak wrote:
 > I would think the main possible performance improvement is if there is code 
 > that must be executed when a state changes. It removes the overhead of a "if 
 > (xrs != previous_xrs)" test in every call

There's certainly no check like this right now.

Xr has no data outside the XrState object. That object encapsulates
the entire library state, (that's the whole point of its existence).

 > This may be true if you have objects that are ready to draw all the time. 
 > However in my experience a typical toolkit has a draw() method that the main 
 > toolkit code calls when drawing is needed.

And in an Xr-oriented toolkit, wouldn't the draw method simply pass
the XrState pointer?

 > Also an XrState may be judged too expensive to have a different one for each 
 > object, in which case this has no advantage for OO programming at
 > all.

An object-oriented interface to Xr need not have many XrState objects.

I guess I had always assumed an object-oriented interface to Xr might
look something like this:

 	xrs.MoveTo (10, 20);
	xrs.LineTo (30, 40);
	xrs.Fill ();

I think we would all agree that this is quite free of visual
clutter. And it turns out that this maps best to the API as it now
stands, (with an explicit XrState pointer).

With an implicit XrState parameter, it would only be valid to have a
single instance of the XrState object in the object-oriented code
which seems exceedingly awkward to me.

I do realize that the code above is in a wrapped style without the
cross-language cut-and-paste feature you were proposing earlier. I
don't see this as a big drawback personally.

If I were to code in a language other than C, I would want my Xr
interface to act as an integrated part of that language.

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                      cworth at isi.edu