- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sun, 10 Feb 2013 15:22:22 +0100
- To: www-svg@w3.org
Jonathan Chetwynd: >you had not addressed my comment on 'scale' and your thoughts may be of >interest. scaling/manipulation of 'time'? SMIL has a module for this and I think, there is a requirement to get something like this for SVG2. But what you can do with this is more to simplify some typical problems, like doing the animation backwards or with another timing as noted. But the recommendation you referenced is only about more precise time stamps, one already has for example in PHP - therefore nothing really new: http://www.php.net/manual/en/function.microtime.php Computers have this time information, but if they are connected to a network with proper time information (NTP, GPS, wireless networks for mobile phones etc), such time stamps are required to be corrected, because the local quarz oscillator of the device is not precise enough. Usually such corrections are done with other programs than those trying to display some SVG or (X)HTML, therefore maybe not easy to follow such a recommendation with a normal viewer with limited access to the control or interpretation of the primary signal of the local quarz oscillator. As we can see with the CSS2.1 unit problem for lenghts, for several implementors it was not even desirable to get proper information about the screen resolution, why should it work better for proper time information? ;o) >my feeling being that where one has a complex variety of timed events, >it may be helpful to have a simple way to speed up - slow down the whole >animation, This can be more difficult with declarative options, because attributes of animation elements are currently not animatable themselves. Obviously already today one can switch to another animation element with different duration or keySplines with some event, but for example my suggestion to have an option in SVG to conserve and to reuse the current value of an animation effect was rejected, therefore it will remain difficult to switch with a (user-)event in the middle of an animation to something different, but with the effect, that it looks like a continuation. With to-animation one has a simple access to a small subset of such effects, but unfortunately the usual viewers have bugs and gaps for to-animations, therefore in practice not really usable today due to broken implementations. With CSS-transitions one may have access to a similar subset, once it becomes a recommendation, but they are only decorative and there are not really precisely defined events in CSS, only vague changes of states. Your use case to slow down or speed up depending on (user-)events sound useful in specific situations, but if already simpler suggestions are rejected and to-animation implementations remain broken, there is not much hope for some advanced approaches for more declarative manipulations of animations. Currently there is not even an option to pause an animation declaratively, this would be one simple and apparent option to start with - already helpful as an accessibility feature, especially if animations are used together with elements like video, audio, animation (SVG tiny 1.2, respecitively SMIL or 'HTML5'). But I think, there is an idea as well to use something like the SMIL time containers in SVG2, this may help already in some situations to get more sequenced content with user interactivity. Of course, one may have another decorative effect, if one is able to manipulate animation elements with ecma-scripts, but because I do not use them and this option is not related to content, I have no experience with such an approach. On the other hand, you cannot manipulate time in real life (well there are funny situations in relativistic spacetime, but usually we live in a simpler part of the universe). And the options in computer games to restart at a specific time in the past, if you fail, feels always like cheating - therefore I think, the manipulation of declarative animations is limited to use cases without the demand to simuate something realistic ;o) But for other uses cases - why not to think, how to do this? Currently the solution may depend strongly on the specific problem one wants to solve with this. Olaf
Received on Sunday, 10 February 2013 14:22:53 UTC