Excelllent! Since we manually handle the animations in our app (adapting
to the lack of support in older batik I guess) we have a play/pause
button in the app itself which controlls the process. Using the
pauseAnimation() right after the document loads, seemed to have done the
trick!! Thank you again!!
Cameron McCormack wrote:
Hi Martin.
Martin Constantine:
Has anyone peeked at this yet? Can I provide any clarification? Thanks.
Well…
Batik 1.6 stable did not show animations when the document was loaded.
That is because SMIL animation was not implemented in Batik 1.6.
That is, after the document was loaded, it was displayed in the canvas
in its original state. The idea is that the user controls the showing
and stopping of the animations with a play/pause button. The reason
for this is that the animations have to be in sync with a recorded
voice. These animations are simply annotations that go along with
someone giving a presentation.
In a recent svn build (r518077) the animations show up when the
document is loaded onto the canvas.
That is because SMIL animation is now supported in the code in SVN.
Is there a way to get the behavior
of the 1.6 stable release? We don't want to see any animations until
the user hits the play button, but we do want to see the document
prior to when the animations were applied. I suppose this translates
to: process the document, but not the animations...or if you have to
process the animations, don't show 'em.
Which play button do you mean? One in the document, or in your app, or
in Squiggle? In Squiggle the play button controls processing of the
document altogether–pausing will stop processing any script and
animations, but it does not “pause time”.
If you want Squiggle or the JSVGCanvas not to run animations until
something is clicked, then we can’t make that change, since animations
are meant to start when the document is loaded. You however can control
whether animations are running from within the document, by using the
pauseAnimations and unpauseAnimations methods on the SVGSVGElement
interface.
If you really wanted to, you could subclass JSVGCanvas in order to
provide a subclassed BridgeContext uses a subclassed
ScriptingEnvironment that causes the SVGAnimationEngine not to kick off
at the same time as the SVGLoad event is dispatched. Doing it from
within the document sounds easier, though.
Cameron
