Brian Birtles’ Blog About

Fill modes (nearly) there

・Archive ・SMIL

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: smil-anim-2005-10-04-2138.patch

Previous Post
Additive animation
Next Post
SMIL work: performance and integration

Comments

gandalf

I applied the patch, added --enable-smil, recompiled Firefox, but your testcase doesn’t work for me at all 😞

Brian

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?

Twitwi

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 !

Brian

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

https://birtles.blog/smil/patches/smil-anim-2005-10-09-1112.patch

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

Twitwi

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 client.mk and firefox sources:
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot checkout mozilla/client.mk
(use “anonymous” password)
cd mozilla
make -f client.mk 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

Twitwi

(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 client.mk 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.

Olaf

Adobe and Opera behaviour in:

https://birtles.blog/smil/tests/frozen-to-animation.html

I think, their behaviour is correct, according to the specification
animation with values overwrite those with from, to, by.
Anyway the later animation has to overwrite the earlier, because it is
not additive.

Why do you think, there should be a visible effect for the to animation
for y?

Brian

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

https://birtles.blog/smil/tests/simple-to-animation.svg

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

Thanks again Olaf!

Brian.

Olaf

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)

Brian

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.

Olaf

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

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)

Leave a reply

Most markdown like **bold** and _italic_ is supported.

Never shown. Only used for looking up your gravatar.

Optional
https://