[cairo] Cairo with glitz backend

[Chris Wilson]

On Wed, 2009-03-04 at 12:35 +0200, Argiris Kirtzidis wrote:
> I'm the one to "blame" for http://github.com/akyrtzi/cairo-gral/tree/master
> The reason I didn't introduce it in the cairo community is that I want 
> to make sure that it is working on linux first (only tested on windows 
> currently)
> and preferably get it to work directly with OpenGL (not Ogre3D).

Sorry, I was just annoyed to find this little gem via Google. I also
found the comments made by others in the discussion forum to be
incredulous and thus further fueling my anger. :-(

I was impressed, just my judgement was clouded by anger. But please help
us improve Cairo! :-)
 
> In any case, since it got noticed after all, I would appreciate and be 
> very interested to hear your thoughts about the fundamental flaws that 
> you found in the "cairo-gral" approach.

>From memory...

The major issue is antialiasing. AFAICT, you appeared to use a
single-pass stencil approach to generate the mask for the composite
operations, and so limited to no antialiasing. The conventional approach
of using a multi-pass jittered stencil mask usually destroys the
performance advantages of direct-rendering (and is still inferior to the
255x17 subsampling provided by spans). However, there is an argument
that some people are willing to trade quality for speed.

The duplication of cairo-path-stroke.c was a bad sign, especially
considering how intricate (i.e. full of bugs! ;) it is and needs to be
rewritten to accommodate stroke-to-path (including a stroke-to-shaper,
i.e. to allow backend to plug in their own callbacks).

[That's pretty much the point at which I had enough, and moved on.
However, I hope a few wiser people have now had the opportunity to look
over your code and can provide constructive criticism. Alternatively,
tell us what is broken and how we can improve Cairo with respect to
providing a fully accelerated backend.]

I'm also wary of introducing a new out-of-tree abstraction layer,
especially if its only user is likely to be cairo. (Another glitz
monster.) Either OGRE is interesting enough to merit its own backend,
sharing components with the rest of cairo (but more likely with DirectX
and GL) and helping to shape those internal layers (for example,
coordinate precision of paths, pattern handling, filters etc) - or not.

So not to end on a negative note... There are lots of good ideas in
cairo-gral, which I want to incorporate into cairo. So please continue
to have fun with Cairo, and help us to help you!
-ickle