Re: Purpose and synchronicity of timeupdate events across devices?

The timeupdate event is quite useful for some cases, e.g. update a css
slide bar, print the formatted position etc - stuff that needs to be done
periodically, but not really synchronized.  At least, it does save me some
fiddling.  Using the timeupdate event, which could arguably be improved no
end, as is allows various ui components to be plugged in trivially. Also,
the timeupdate is of course paused if the timing object is paused, so it
does save some resources (as expected) when stuff is not happening.  Wierd
stuff, like the 5Hz, not sending the position in the event etc are all
inherited from the HTML5 Media Elements. ;-)

We already do have some setInterval and setTimeout functions in our support
libraries that are very useful, and they will of course provide
synchronized callbacks, taking skips and playback speed into account.

Regards,
N


---
Dr. Njål Borch
Senior researcher
Norut Tromsø, Norway

On 8 June 2015 at 21:53, Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
wrote:

> Hi Francois
>
> Excellent work with the timing object ! Here's a quick reply on the
> timeupdate event.
>
> The timeupdate event was never intended to be in sync across devices. Of
> course, one could support this, but I'm in favour of doing this as a
> separate thing, for instance by providing new versions of setTimeout or
> setInterval - as indicated in the task description. (possibly we need new
> names here to avoid confusion)
>
> Personally, I'm no huge fan of the timeupdate event (with fixed
> frequency). In my opinion, the choice of frequency should be in the
> consumer of the timingobject - for instance allowing different components
> to sample the timing object at very different rates.
> The timeupdate event was only introduced in the spec to mimic the
> pulse-based timing model of the HTMLMediaElement (which is about 5Hz),
> which programmers are used to in the Web environment. Ironically, a central
> motivation for the timing object is to escape this pulse-based timing
> model, so in that regard the timeupdate event may even be
> counter-productive.
>
> So, if you want to remote it - I would be ok with that :)
>
> Ingar
>
>
>
> 2015-06-08 17:35 GMT+02:00 Francois Daoust <fd@w3.org>:
>
>> Continuing to think out loud here,
>>
>> What is the purpose of the "timeupdate" events as currently defined?
>>  http://webtiming.github.io/timingobject/#events
>>
>> More specifically:
>>
>> 1. Is the expectation that "timeupdate" events get fired synchronously
>> across devices, or that they are associated with the "position" of the
>> timing object? The spec does not suggest that and I did not do that in my
>> prototype implementation, but then it seems a bit useless if it is only a
>> shorthand to the local setInterval function.
>> 2. Why a 5hz fixed frequency? Is it a common frequency for most
>> media-related operations? Not having any sort of flexibility seems weird.
>>
>> I guess I see value in having something synchronized across devices and a
>> bit more flexible, synchronized versions of "setTimeout" and "setInterval"
>> in short that could be exposed on a TimingObject instance. I see that it is
>> in fourth position in the list of tasks for the group, so that's good ;)
>>   https://www.w3.org/community/webtiming/overview/
>>
>> Francois.
>>
>>
>