[cairo] cairo-cairo backend?

[Helge Bahmann]

Hello list!

As the subject suggests, I would like to have a cairo backend surface for
cairo -- i.e. a "surface" that acts like a "display list" in OpenGL terms,
collects drawing commands and is able to replay the commands on other
cairo drawing contexts. The important point here is that I would like to
record the commands without "semantic loss" -- lines should be lines,
areas should be areas, and glyphs should be glyphs.

Actually, I have an implementation cooked up -- just to see if it would be
difficult to do, and were problems are lurking -- that is working "mostly"
correct, but not quite (ownership of patterns issues etc...). I am more
than happy to undertake a complete and correct implementation if there is
interest (I hope there is :)

The major stumbling block is the lack of a "stroke_path" equivalent to
"fill_path" in the surface_backend structure. Hooking in an equivalent is
a rather trivial change, less than 20 lines or something. Is there any
reason no such function has been provided yet, other than that none of the
existing backends has use for it?

Clipping areas are another, considerably more difficult problem; basically
I have no use for clipping areas that are more complicated than a (union
of a small number of) rectangle(s), but this is certainly not the
"correct" way to handle clipping.

To explain a little bit where I would find use for this capability...
Currently I am working on a (networked) presentation system where I would
like to use cairo for drawing. In this system the entity generating the
drawing commands is decoupled from the entity performing the drawing
operations, so I need to store and convey them. The approach up to now has
been to "wrap" all cairo calls and do the recording myself; this "feels
wrong", because a) it would be nice to allow the application to use cairo
as "universal" drawing kit and not care about the destination and b)  the
infrastructure required is for the most parts already present in cairo.

But maybe the concept of a "display list" is more useful than that --
several backends could, at least in theory, interpret them natively (I'm
thinking of OpenGL or postscript functions here). Maybe
"self-virtualization" of cairo is a sufficiently interesting ability in
itself.

What do you think? Do you consider it worthwhile, or should I stick to
wrapping cairo?

Best regards
-- 
Helge Bahmann <hcb at chaoticmind.net>                     /| \__
The past: Smart users in front of dumb terminals       /_|____\
                                                     _/\ |   __)
$ ./configure                                        \\ \|__/__|
checking whether build environment is sane... yes     \\/___/ |
checking for AIX... no (we already did this)            |