[cairo] cairo-cairo backend?

[Carl Worth]

On Tue, 31 May 2005 17:12:58 +0200 (CEST), Helge Bahmann wrote:
> 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.

Hi Helge,

We are quite interested in having this capability, and we've discussed
it a fair amount in the past. One of the most pressing needs for this
capability is in supporting a more efficient PostScript backend. The
current PostScript backend uses image fallbacks for everything. A more
efficient version would emit native PostScript for as many objects as
possible and only resort to image fallbacks when required by the
limitations of the PostScript rendering model, (eg. when drawing with
a source without uniform alpha==1.0). The anticipated means of
supporting this is to collect the drawing operations in a "meta
surface" which can then be replayed, (partially to native PostScript
and partially through the image fallbacks).

Kristian Høgsberg has been doing the most recent investigations into
the meta surface and his latest post on the topic can be seen here:

	http://lists.freedesktop.org/archives/cairo/2005-May/003942.html

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

It's great to hear that you've already got some code in place. It
sounds like we'll need some coordination between you and Kristian
now. I don't know how much code he might already have.

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

No, no reason. That sounds like a very simple addition.

When I last gave some thought to meta surface problem, it seemed to me
that one of the biggest pieces of new work would be efficiently
capturing surface-based source patterns. We may need a new
copy-on-write mechanism to keep memory needs from blowing up too much.

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

This is another area where the backend interface should shift in the
direction of being path-based, (or at least allowing it). I know that
Kristian is already planning on doing this work as well, and Keith
left some guideposts in his recent rework of clipping to remove the
BAD_NESTING restriction.

Welcome aboard. I hope you can have lots of fun here.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050531/9cc396a5/attachment.pgp