[cairo] MOZ-SVG-cairo (was: usable libsvg-cairo?)

[Liam Breck]

A "retained canvas" (if I interpret the term correctly) is what we're
building. It's basically an SVG object model designed for incremental
updates/rendering.

Parsing is omitted as the model is assembled procedurally from a high-level
description (not SVG). In our case this is handled on a server that then
sends SVG fragments to clients in a pre-parsed format.

Our canvas doesn't need all the dynamic SVG features (Javascript, forms),
but does need animation, style sheets, cursors, and others. Our canvas also
needs some extensions to SVG, e.g. to enable "client-specific" elements
when the canvas is a master for multiple remote screens.

Then we need a way to render the object model in cairo; it sounds like we
could use a lot of the libsvg-cairo code. The model interpreter obviously
has to drive animation, etc.

I'd be happy to make our current work the starting point for a
collaboration to develop an SVG-based canvas library with a cairo backend.

Our current object model and interpreter are somewhat primitive - just a
prototype - but you can download the code and a demo.
  http://networkimprov.net/airwrx/
In the source dir, awscene.cpp creates the object model (on server), and
awsvgterm.cpp maintains a copy and renders it (on client).

Liam


At 05:43 PM 5/12/05 -0700, you wrote:
>On Thu, 12 May 2005 19:51:20 -0400, Liam Breck wrote:
>> What we want is simply an SVG-based API for cairo, so you can write:
>>   XxSvgRect(aContext, aSvgParameters);
>>   XxSvgTspan(aContext, aSvgParameters, textbuf, textlen);
>
>I'm still not clear on what you want here. You mentioned earlier in
>the thread that you didn't want this library to do SVG parsing. So
>what's left in an "SVG-based API for cairo"? If it's just an
>immediate-mode drawing API with an SVG flavor, then I would propose
>that cairo provides a better immediate-mode API anyway. But if you did
>want that, there's not really a lot of work involved, and it's
>basically done already in libsvg-cairo/src/svg_cairo.c:
>
>But I imagine you might want a lot more than just that.
>
>> I don't want to duplicate the work of libsvg-cairo or librsvg if not
>> necessary; is my impression that these projects are not evolving as fast as
>> Moz-SVG correct?
>
>In this context, libsvg-cairo and librsvg should be considered one
>work. They share common heritage and we'd like to get them re-merged
>at some point, (librsvg has gained filters and CSS support since
>libsvg-cairo split off, and librsvg is now getting support for
>multiple backends so it should be able to start drawing with cairo
>soon).
>
>So this codebase provides a fairly complete base for static SVG, but
>nothing dynamic yet. As far as static SVG goes, I'm not aware that
>there is a lot of evolving that needs to happen here.
>
>If it's the dynamic parts of SVG that you want, (which I'm guessing it
>is), then some new work is needed. I haven't compared the
>librsvg/libsvg-cairo stuff closely enough with the Mozilla stuff to
>posit a guess as to which might make a better base for a standalone
>dynamic SVG library.
>
>One approach might be to make a retained-mode "canvas" on top of
>cairo and then do the dynamic SVG stuff on top of that. That canvas
>library would be quite useful to a fair number of other projects.
>
>-Carl
>
>Attachment Converted: "D:\Email Files\Re [cairo] MOZ-SVG-cairo (was"
>