[Xr] Can the xrs argument be removed?

[Carl Worth]

On May 22, Owen Taylor wrote:
 > Since Carl (whose opinion matters, mine doesn't) has been polite and
 > receptive here, I'll take the opportunity to be unfriendly and 
 > combative :-)

Thanks Owen. Let's see if we can keep up this good cop/bad cop routine
in the future. Could come in handy.

 > There *are* advantages to using an implicit state
 > 
 >  - API simplicity ... you make you the code even simpler looking
 >    (though Xr is already better than almost any other drawing
 >    API I know in this regard)

This is what looked appealing to me.

 >  - Possible performance if you can get the context fast enough...

I don't care much about this. It's not clear that this will become
relevant, (and I'm loathe to fix performance problems that aren't
there). Wait and see.

 > There also disadvantages:
 > 
 >  - Trouble mapping the API into object oriented languages.

Good point.

Another troublesome scenario: Imagine a program being converted
incrementally to Xr. In this case it would be convenient to create and
destroy several independent XrState objects within the same thread at
various levels in the code, (a perfectly legitimate model as long as
XrCreate/XrDestroy are plenty fast). But this would be unacceptably
error prone if the user had the burden to restore the previous XrState
each time.

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

The multiple surface issue is not so much a problem. A single XrState
object can already accept different surfaces at different
times. There's also the possibility, (not in the API yet), to let the
user get/set the current graphics state, (which is different than the
XrState object we're discussing here). That could enable the user to
capture separate objects for different surfaces.

But supporting both "library state" and "graphics state" objects might
be too confusing as well. So if we can get away with exporting just
one or the other, I will prefer that.

-Carl