[Xr] Can the xrs argument be removed?
spitzak at d2.com
Thu May 22 18:34:44 PDT 2003
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
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
More information about the cairo