[Xr] Can the xrs argument be removed?
otaylor at redhat.com
Thu May 22 14:45:26 PDT 2003
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
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
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
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
What does XrFill() look like if there is no XrState object?
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
- 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.
More information about the cairo