[cairo] Glitz surface?

Carl Worth cworth at cworth.org
Mon Feb 23 14:57:56 PST 2009

On Mon, 2009-02-23 at 20:43 +0100, Oscar Lazzarino wrote:
> Just out of curiosity, what's the status of the "glitz" surface backend?


> Is it still mantained?

Not consistently. Sometimes people appear on this mailing list that
claim to be using it actively.

> Will it ever be promoted to a non "experimental"
> backend?

It's hard to predict the future. :-)

But the two requirements we have to mark a backend as "supported"
instead of "experimental" are:

    1) It passes the test suite

    2) It has an obvious, active maintainer willing to keep it up

I'd soon like to be able to also add "3) It's included in our daily,
automated testing" to that list.

> Is it worth using?

That depends a lot. As I said, some people have found it useful as is,
(or maybe they even have patches they've been using that need to be
landed upstream).

Other people I've talked to that are interested in doing cairo-on-opengl
have looked at glitz and decided it's the wrong thing for several

    1) It targets the Render interface rather than cairo's backend

    2) It targets very old X/OpenGL infrastructure, not taking advantage
of any recent developments, (such as actual memory management).

As an alternative, for example, Eric Anholt has recently been playing
with a new cairo-gl backend that addresses both of these points. It's
not yet complete in any sense, (for example, it only accelerates cairo's
composite() interface), but he's already measured it as being 4 times
faster than using cairo-xlib on identical hardware*.

A different approach is Chris Wilson's experimental cairo-drm backend.
This takes advantage of code from the X server's drivers for Intel
hardware, (rather than sitting on top of OpenGL), and presumably sees
similar improvements.

I'll let Eric and Chris reply with pointers to their code and caveats as
they see fit.

So there are some interesting approaches to hardware-assisted cairo that
are being actively developed now. None of those currently have the name


[*] The 4x improvement might be almost entirely from avoiding the
overhead of sending trapezoids to the X server, and then incrementally
rasterizing them. An interesting experiment would be to change
cairo-xlib to rasterize client-side and push the mask to the server
before compositing, (which would also allow for doing spans-based
rasterization of polygons). The original idea behind tessellation and
trapezoid-rasterization was to take advantage of hardware-based
trapezoid-rasterization, but since that isn't is sight now, (even after
all this time), we should probably cut out all the unneeded overhead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20090223/34eb539f/attachment.pgp 

More information about the cairo mailing list