[whatwg] VIDEO Timeupdate event frequency.

[Roger Hågensen]

  On 2010-09-11 05:23, Eric Carlson wrote:
> On Sep 10, 2010, at 8:06 PM, Biju wrote:
>> On Fri, Sep 10, 2010 at 7:05 AM, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com>  wrote:
>>> Incidentally: What use case did you have in mind, Biju ?
>> I was thinking about applications like
>> https://developer.mozilla.org/samples/video/chroma-key/index.xhtml
>> ( https://developer.mozilla.org/En/Manipulating_video_using_canvas )
>>
>> Now it is using setTimeout so if processor is fast it will be
>> processing same frame more than on time. Hence wasting system
>> resource, which may affect other running process.
>    Perhaps, but it only burns cycles on those pages instead of burning cycles on *every* page that uses a<video>  element.
>> If we use timeupdate event we may be missing some frames as timeupdate
>> event is only happen every 200ms or 250ms, ie 4 or 5 frames per
>> second.
>    Even in a browser that fires 'timeupdate' every frame, you *will* miss frames on a heavily loaded machine because the event is fired asynchronously.
>> And we know there are videos which a have more than 5 frames per second.
>    So use a timer if you know that you want update more frequently.

Hmm! Once you get up to around 60FPS (1000ms/60=16.66666...) you are 
getting close to 15ms per frame,
and unless the OS is running at a smaller timer period that is all the 
precision you can get.
I believe Windows Media Player is using 5ms periods, and the smallest 
period advisable on a modern Windows system is 2ms,
1ms is most likely not consistently achievable on any typical OS (there 
will be fluctuations) that is not a real time OS (few end user OS are 
these days)

This would have to be synced to the display refresh rate instead. (no 
point processing frames that are not displayed/skipped anyway),
I can't recall any browsers exposing vsync. (does any?)


-- 
Roger "Rescator" Hågensen.
Freelancer - http://EmSai.net/