[Xr] Can the xrs argument be removed?

[Owen Taylor]

On Wed, 2003-05-21 at 17:28, Bill Spitzak wrote:

> 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.

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

The above is absolutely ridiculous.

If you can write 

 void MyCoolXrDemo ()

You can write 

 void MyCoolXrDemo (XRenderState *xrs);

100% as easily.

And API optimizing for writing "drawing demos" is entirely wrong, in any
case. What should be optimized for is things that applications want
to do.

There *are* advantages to using an implicit state - though the 
above isn't one of them.

 - 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)

 - 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.

   (But I don't think API point calls are going to be a bottleneck
   with Xr ... it's not like GL where you have millions of vertices
   flying around)

There also disadvantages:

 - 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.

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

   Fill what?

   What's the number one problem people have programming with
   GTK+? They have trouble writing the rest of their app
   because they don't understand pointers and malloc(). 
   It would be a mistake to optimize Xr to be incredibly
   easy to use from a language that is inherently difficult
   to use.

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

   GL is sort of like postscript in that there is usually a 
   single target you are drawing into. That's not necessarily
   true for all 2D drawing programming.

I'm not necessarily opposed to an implicit state, but I think
the question of what the API looks like for object-oriented
languages is a crucial one.

Regards,
                                      Owen