[Xr] Can the xrs argument be removed?

Bill Spitzak spitzak at d2.com
Wed May 21 14:28:31 PDT 2003


I would like to recommend that you remove the "XrState*" argument from Xr, 
and make it work much more like OpenGL where there is an implied static 
context variable.

The benifits are that many pieces of software could then use the Xr calls 
directly to draw things. This will greatly enhance portability. Notice that 
there are lots of OpenGL drawing demos that can be imbedded into almost all X 
toolkits, Windows, and OS/X programs. Conversely notice that there are *no* 
such Xlib or DirectX demos, all of them are entire programs. This is directly 
due to this "context" argument.

I think the elimination of the need for toolkit and platform specific wrapper 
functions around all the Xr calls (or toolkit or platform-specific calls to 
get the XrState) is absolutely vital for the success of Xr.

My recommendation is this:

  There is thread-local static storage contining an XrState*. You read it 
with a new call "XrState* XrGetState()" and "void XrSetState(XrState*)". All 
functions that take an XrState* argument are changed to use this static 
variable instead, including XrDestroy().

  The initial value is NULL. Doing any calls other than XrGetState, 
XrSetState, or XrCreate with NULL produces undefined results. (I recommend 
this in case there is expense involved in creating an XrState, it can be 
deferred until the first drawing is needed)

  XrCreate() should both return the new XrState and also set the it as the 
current one.

 XrDestroy() sets the current state to NULL.

Other benifits:

If you add a rule that you are not allowed to use an XrState in more than one 
thread at a time (easily checked with a usage bit set/cleared by XrSetState) 
then you may be able to eliminate any locks in the XrState itself. I think 
this does not cause any harm to the usability of the API and could be a big 
win in speed.
 
Because the method used to make thread-local static variables is hidden this 
is also much more portable than any solution a user of Xr can do.

Because the state only changes when XrSetState is called, large amounts of 
cached data may be calculated and stored for the current one, while all the 
others are much smaller.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com




More information about the cairo mailing list