Re: High Resolution Time

Hello,

the term 'High Resolution Time' for something like a microsecond sounds
a little bit strange - I work with pulsed lasers with a length of about 10 
nanoseconds and today it is possible to produce pulses clearly below
a femtosecond - this means one can resolve/analyse processes with a time
structure below a femtosecond ;o) 
In several areas of physics a microsecond is close to eternity ;o)

However, times in SVG can be given with a millisecond unit and it does not
use integers, but has possible fractions as well, therefore it is no problem
to write dur="0.0001ms"  already with the SVG tiny restriction on the allowed
number of digits.
This means, the allowed resolution of time related attribute values is already
in the SVG tiny defined to be below a microsecond.
With a wallclock-sync-value one can provide fractions of a second as well.

Accuracy is more difficult, one has to discuss deviations per duration,
for example the deviation for an interval of a second or a day.
In SVG there is only the restriction, that the visible result should be
more accurate than one device pixel (for SVG tiny, better for more
advanced viewers). This can be used for testing.

If required and if the computer is connected to an ntp-server or atomic
clock, it should be no problem to get defined durations with an accuracy
or resolution below 1 microsecond, if the temperature of the computer is
more or less constant.
If not connected, still with a quarz-oscillator typically one has deviations 
below one second per day (could be much better - but we always get
only the cheap oscillators in computers ;o) 

And in SVG for example with a discrete animation with an end within the 
active duration, it is no problem to test at least, that a viewer stops with a
proper timing (due to my tests viewers more often fail here with begin
and end events) - or presents the result properly, that belongs to the
durations and times noted by the author.

If one compares an animation (a timer for example) with a precise clock
(radio controlled for example), due to my tests the resulting deviations
are typically consistent with the estimated accuracies of the quarz oscillator
in the computer and that of the radio controlled reference clock and 
reaction times etc. But such tests provide more information about
the accuracy per day, not what happens within a second.


The usual accuracy problem of scripts compared to declarative animation
is, that they are often designed with loops and sleep intervals, therefore
they shift away from proper timing, because it needs time to execute the
commands.
To avoids this, one needs something like a trigger, what is available
as wallclock value in SMIL/SVG animation declaratively. Or one can use
a declarative animation as a timer for script events to avoid such shifts
in scripts. This should be possible already now with the current
recommendations of SVG.


Interesting in the referenced recommendation is 4.4.
This seems to prevent, that clocks with low accuracy are
corrected to get a more proper timing - but do viewers
have an independent access to timing, if the low accuracy
clock of the computer is connected to an ntp-server and
is corrected automatically? Typically the corrections will
be small enough and in such a way, that the clock is still
monotone, but if it is the advice for a program to ignore
corrections, its timing may shift significantly over a day or week 
- and how to do this practically? Own connection to an 
atomic clock/ntp-server?



Olaf

Received on Saturday, 9 February 2013 19:30:04 UTC