[Xr] Can the xrs argument be removed?

[Bill Spitzak]

On Thursday 22 May 2003 02:45 pm, Owen Taylor wrote:

> You can write
>
>  void MyCoolXrDemo (XRenderState *xrs);
>
> 100% as easily.

My problem is not with this extra argument, but in getting the value of this 
extra argument from deep inside a number of nested calls in some existing 
software that was not written to pass this extra argument down.

>  - Possible performance if you can get the context fast enough...
>    pthread local storage is relatively slow, but the __thread variable
>    extension that has been showing up recently for GCC/GLibc is
>    likely faster than argument passing.

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, and maybe more expensive tests if 
this is supposed to be thread-safe. I suppose also it removes one value being 
copied to a register or the stack for each call. Conversely it adds all the 
overhead of an entire call when the state is changed, and likely software 
will call XrSetState more often than necessary. So my guess is that 
performance is not really going to be any better or worse.

>  - Trouble mapping the API into object oriented languages.
>    And while Xr may be a C API, most people will probably
>    being using it from Python, Java, C#, etc in the long
>    term.

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. In this case it is easier for the 
toolkit to defer creation and management of the XrState until it is ready to 
call this method. Also there is probably the overhead of adding a this->xrs() 
call to every Xr call, C++ compilers currently are probably not smart enough 
to realize that this pointer does not change when other methods on this are 
called. If you eliminate that call by "wrapping" all the Xr calls then you 
have the problem that the user cannot call any new functions in Xr until the 
toolkit is updated.

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.

>    What does XrFill() look like if there is no XrState object?

Just like that: XrFill()

>  - Less obvious operation, especially if you want to mix
>    operations on multiple surfaces.

This I would admit is the biggest problem. People may write code that calls 
XrSetState many many times and completely destroy performance if Xr was 
written to assume it will be called rarely.

-- 
 spitzak at d2.com