[cairo] MOZ-SVG-cairo (was: usable libsvg-cairo?)
svg at networkimprov.net
Thu May 12 18:58:24 PDT 2005
A "retained canvas" (if I interpret the term correctly) is what we're
building. It's basically an SVG object model designed for incremental
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.
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.
In the source dir, awscene.cpp creates the object model (on server), and
awsvgterm.cpp maintains a copy and renders it (on client).
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
>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.
>Attachment Converted: "D:\Email Files\Re [cairo] MOZ-SVG-cairo (was"
More information about the cairo