W3C home > Mailing lists > Public > www-svg@w3.org > February 2012

Re: Agenda request: Presentation attributes in animation sandwich model

From: Nikolas Zimmermann <zimmermann@physik.rwth-aachen.de>
Date: Sat, 25 Feb 2012 10:24:46 +0100
Message-id: <30432527-C6FE-4BC8-864B-5A2066F6F063@physik.rwth-aachen.de>
Cc: Dirk Schulze <dschulze@adobe.com>, "SVG WG (public-svg-wg@w3.org)" <public-svg-wg@w3.org>, "www-svg@w3.org" <www-svg@w3.org>, "L. David Baron" <dbaron@dbaron.org>
To: Daniel Holbert <dholbert@mozilla.com>

Am 25.02.2012 um 00:46 schrieb Daniel Holbert:

> On 02/24/2012 03:20 PM, Dirk Schulze wrote:
>> Can you give an example of a potential depth-spiral?
> Suppose SMIL is animating opacity from 0 to 1 over one second.  Suppose the first SMIL sample is at 0.1s -- so SMIL will update the opacity to 0.1.  This causes the computed style of opacity to change (from 0 to 0.1).  If we have "transition-property: opacity" set, then that can trigger a transition, spreading this 0-->0.1 change out over some period of time (the transition-duration).  This would happen for _every SMIL sample_ -- we'd get tons of intermediate transitions, smearing out the effects of the SMIL animation and stomping on each other.
> ("death-spiral" might have been an exaggeration, but the point is we'd get tons of probably-unintended transitions being fired)
> So -- to prevent this, Gecko prevents transitions from being triggered by the style changes produced by SMIL animations.
Sounds good - this should be specified as-is, it's really the best solution to avoid these kind problems :-)

>> Please don't take WebKit as reference
> Cool.  (I didn't mean to do so; I was just stating the facts. :))
WebKits SMIL animation still mutates DOM attributes / CSS properties directly (as you'd script the animation via setAttribute), we're in the process of finally enabling animVal, and get rid of that. Stay tuned.

> P.S. I posted a testcase with CSS animations competing against SMIL, here:
> http://people.mozilla.org/~dholbert/tests/smil/compat_tests/animationsVsSMIL_v1.svg
> In both Webkit & Gecko, the CSS animation "wins" there.  Opera ignores the CSS animation completely. (I'm not sure about their css animation support.)  (I'm not testing IE because I'm on Linux at the moment.)
I'm really looking forward to a set of testcases like this, it will help us a lot.

Slightly related:
I've recently reworked our SVG animation JS test harness in WebKit to use standard SVGSVGElement.pause/unpauseAnimations/setCurrentTime APIs to drive the SMIL timeline.
I'm embedding an external SVG file via <iframe>, request its SVGDocument, and drive its timeline manually, to sample at certain points defined in JS, firing a callback.
There are functions available like shouldBeCloseEnough("rect.width.animVal.value", "150", 0.01 /* tolerance */) to ease testing.

When running the test harness html in the browser, it loads your external SVG file, waits for the document load event, which falls together with the SVGLoad event, and thus the start of the SMIL animation timeline, then it jumps to the times you intend to sample one after the other, asynchronously, so repainting can also be tested as well. This currently works in at least Opera/WebKit, and I think it also worked in FF nightlies, will have to retest.

If we want to work together on creating a new set of test cases regarding SMIL/CSS Animations/Transitions that are intended to work across all browsers, this harness is probably helpful. If there's interest, I'll reduce a self-contained version of the harness, which samples the W3C-SVG-1.1 testcases, animate-elem-02-t.svg .. until animate-elem-20-t.svg checking baseVal/animVal at all interessting sample points. (eg. dur="2s" calcMode="discrete" from=".." to="..", I'll sample at 0.0s, 1.499s, 1.501, (1.999, 2.001, if fill!=freeze), 60s) and so on. The harness could be easily extended to test CSS animations/transitions as well, together with SMIL.

I still look forward to the day, where we have a 'Run animation tests' button on w3c.org/Graphics/SVG and get a score ;-)

Received on Saturday, 25 February 2012 09:25:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:34 UTC