Re: Animation support in librsvg

On Wed, Jul 23, 2008 at 05:37:30PM -0400, Dominic Lachowicz wrote:
> Hi Bas,

Hi,

> I wonder if something like Webkit's port of KSVG wouldn't be more up
> your alley.

Thanks for your effort in minimizing my work. :-)  However, I like to
program with Gtk, so I don't want to use KDE things unless what I want
is not possible with Gtk (and it's not feasable to implement it).

> Animation is going to be a lot of work,

Yes, I am expecting that, indeed.  That's also why I'm writing my plans
here before implementing them. :-)

> and I'm not sure that I'd want it in librsvg.  It's a very good, fast
> static SVG rendering library, and I'd like it to stay that way.

I like that, too, and I think my ideas don't change it very much.  The
point is that the javascript library is external (and possibly optional,
even, if you disable it, but then the XML parsing must be duplicated in
librsvg).  I'm taking the XML parsing part out of librsvg, but I'm
keeping the rendering part (which does all the interesting work, I
think) almost unchanged (one thing I forgot to mention is that it should
support declarative animations, but I don't expect that to be very hard;
all it needs to do is "render current DOM at a given time").

It is in fact important that it will stay very good and fast for
rendering static SVGs, because during animations it's doing that all the
time, and it shouldn't overload the processor. :-)

Of course animation support shouldn't mean that animations become
obligatory.  Users should still be able to render static SVGs.
Personally, I'd prefer it if even for static SVGs javascript is
executed if it is present (but without events), so that what is rendered
is the start of the animation.  This would require the javascript parser
to be linked even for static images.  But if you want users to be able
to disable javascript, I don't have a problem with making that possible,
by linking the library on demand (with dlopen).

For clarity, I don't want to change the interface for loading images at
all.  I only want to extend it for programs which want to support
animations.  Old programs must not need changes to use the new library.

> Besides, your proposal sounds like (more or less) a complete
> replacement for librsvg and not an enhancement to it.

That is certainly not my intention. :-)  While the javascript part may
become larger than librsvg, it does not become a part of it.  Librsvg
will continue to be a library for rendering static SVGs.  It can just be
combined with a javascript parser which can feed it new source at events
(timed or otherwise).

If I would want to write a replacement, I could of course take the
interesting parts and use that as a basis.  I would however consider
that a fork, because I think I'm leaving most of the library as it is,
and I prefer not to do that.

If you're not convinced that it's a good idea, how about yet another
split:
- one library for XML loading, which manages the DOM (libdom)
- one library for rendering the DOM from that library (librsvg)
- optionally a library which messes around with the DOM, the javascript
  parser (libjavascript)

librsvg will only be linked to libdom.  If a program wants to use
animations, it can link to librsvg and libjavascript, which can both
interact with the same data (managed by libdom).  If it doesn't, it just
uses librsvg as it would currently do.

I prefer to not make the javascript part depend on librsvg, so that it
may be used for other DOM-structures, such as web-pages, as well (with a
renderer, of course).

As I said, I would prefer direct javascript (not triggered by an event)
to be executed at load time, so I would prefer the other approach.  But
if you like this better, it is acceptable to me as well.

And of course, if you don't like any of it, I'll have to go find some
other way to do what I want. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Librsvg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/librsvg-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIh7mMFShl+2J8z5URAhi8AJ40ZzW2tWyBqw8nRL1P452sGnAXpgCg1iDP
q1ww7r+Ex/ZpXbShit8PJe8=
=Ifr0
-----END PGP SIGNATURE-----