Status updates

Fill modes (nearly) there

Aided by flat surf but hampered by perfect weather I’ve spent most of the last week tidying up my code and updating the documentation on the wiki. The latest patch is hopefully much better, or at least not quite as hideous as it was in some parts.

Fill modes are now implemented except for one edge case of a frozen to animation that is stopped in the middle of the simple duration. It’s the third case in this test.

I’m putting feature work on hold for a while to focus on a few obvious optimisations such as suspending the timer when it’s not needed.

Here’s the latest patch:

11 thoughts on “Fill modes (nearly) there

  1. Bummer. If you’ve got a chance, drop by #svg and let me know a few more details (e.g. OS etc.).

    Ah, but first, did you regenerate the configure script and then re-run configure? If you have a look at some of the recent posts I’ve described a little bit about that.

    And did you try any of the other test cases?


  2. What is your base working version? By the way, I wanted to try your patch yesterday (with a up-to-date cvs version) but got a little patch rejection (due to a renamed method in the patch context and that I fixed) and compile errors.
    I am really interested in testing animations, could you give me the checkout date of your base version?
    Thx in advance and thx for your job !


  3. Hi Twitwi,

    I can’t remember the checkout date of the previous patch but here’s another patch based on a checkout on 9th Oct 05. It’s got a big of profiling code in there but it shouldn’t matter. Also, I’ve included the configure script in the patch so it’s a bit larger than the last one. (The configure script turned out to be the problem for gandalf so I thought I’d include it).

    Good luck! Let me know if it works or if you’d like me to re-patch based on a more recent checkout.


  4. Hi,

    I checked out and patched. All went fine (expect the patch of the configure but that’s no problem)!

    I just tested your test cases by now, all is working ok.
    I will do some more testing latter, thanks for your job and good luck!
    Perhaps will I propose some help to you but I’m not very familiar with the mozilla architecture and don’t have much time…

    Here are the commands used for my build (if some people need it):

    Check out the mozilla and firefox sources:
    cvs -d checkout mozilla/
    (use “anonymous” password)
    cd mozilla
    make -f checkout MOZ_CO_PROJECT=browser

    Configure your build:
    emacs .mozconfig
    (here is my .mozconfig file:
    ac_add_options –enable-application=browser
    mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/output-build-dir
    ac_add_options –enable-default-toolkit=gtk2
    ac_add_options –enable-xft
    ac_add_options –enable-static
    ac_add_options –disable-shared
    ac_add_options –disable-tests
    ac_add_options –enable-mathml
    ac_add_options –enable-svg
    ac_add_options –enable-smil
    ac_add_options –enable-cairo

    Get the patch and apply it:
    patch -p 3 -u -N


  5. (cont’d) the inferior symbol broke the post

    Get the patch and apply it:
    patch -p 3 -u -N (((inferior))) smil-anim-2005-10-09-1112.patch

    Build and have a coffee and a walk:
    make -f build

    Start the new firefox with a new profile (close any running firefox beforehand):
    cd output-build-dir
    ./dist/bin/firefox -profilemanager

    Hope this helps some people.


  6. Hi Olaf!

    Thanks for your feedback. You’re right! I misunderstood how to animations are prioritised. I’ve fixed it and will release an updated patch today or tomorrow.

    However it’s not the case that values-based animations overwrite to animations. But perhaps what you mean is that if a single animation element has both the values and to attributes specified the values attribute wins (SMILANIM 3.2.2, “If a list of values is specified, any from, to and by attribute values are ignored.”).

    In this test case however the values and to attributes are specified on different elements so they are composited according to the rules for the animation sandwich. I’ve fixed the test case so the to animation adds to the values animation and I still believe the results from ASV and Opera are wrong.

    With the updated test the results I get are:

    First case: ASV displays the correct result (i.e. the to animation comes to dominate). Opera doesn’t seem to provide the additive to behaviour at all.

    Second case: ASV displays the correct result. Again, Opera doesn’t seem to provide the additive behaviour.

    Third case: ASV displays the wrong result. This is a really hard test case. I’m trying to test the part in the SMILANIM spec (3.3.6) that says:

    “The value for F(t) when a to-animation is frozen (at the end of the simple duration) is just the to value. If a to-animation is frozen anywhere within the simple duration (e.g., using a repeatCount of “2.5”), the value for F(t) when the animation is frozen is the value computed for the end of the active duration. Even if other, lower priority animations are active while a to-animation is frozen, the value for F(t) does not change.”

    This is really hard to support, especially when seeking. I’m waiting to hear from Patrick Schmitz (editor of SMIL Animation spec) if my understanding is correct.

    Again, Opera doesn’t seem to provide the additive behaviour.

    This is the first time I’ve tested Opera so I’m not sure what the status of their SMIL implementation is.

    I’ve just tried this simple to-animation from the SMIL Animation spec (3.3.6):

    ASV produces the correct result but Opera doesn’t so presumably Opera doesn’t provide to-animation yet.

    Thanks again Olaf!



  7. The source-code of the example looks now better for me – I think, now
    it fits to the description ;o)

    In my systematic tests I detected some problems with additive
    behaviour of ‘to’ in Opera, too. In general Opera ignores many things
    correlated with animation. They promised full support for SVG tiny, but
    for animation I have an estimate for the probability of correct display
    for a simple random choice animation within SVG tiny of about
    0.18 +- 0.009, Adobe reaches 0.54 +- 0.03 in the same test – both have
    to be improved clearly.
    If you don’t rely on them with your project, you are on a good way ;o)

    Maybe I have to check the ‘to’ behaviour more carefully in my tests.
    For authors it might be helpful to add some additive=”sum” to help
    these user-agents to simplify their decisions – should work better for
    authors, but of course not for tests ;o)


  8. I’ve just tried the Opera 9 preview and they have added support for ‘to’ animation. They’ve also fixed the frame rate for animation.

    For the frozen to animation test case Opera 9 produces the same result as ASV, i.e. it doesn’t provide the result described in the SMIL Animation spec.


  9. I checked Opera 9 TP1 yesterday, too. They really corrected serveral awful
    errors and gaps in SVG tiny support, but in some areas they seem to be
    completely in the dark (end attribute, various events, accumulate,
    keyPoints, funny things with the animation of qubic paths;o) but they
    already want to start to support SVG basic with Opera 9.
    About Adobe I think they are maybe not very interested anymore in SVG
    after they got macromedia or even before. Therefore it is very good, when
    Mozilla, Opera and Konqueror will have a good support for SVG in the near

    Looking much more carefully in the SMIL animation recommendation was
    very useful for me – I was able to detect several misunderstandings and
    corrected some of my own examples and add some more. At the end this
    discussion was very useful for me ;o)


Comments are closed.