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
<silviapfeiff...@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/
