- From: Roger Hågensen <rescator@emsai.net>
- Date: Sat, 11 Sep 2010 14:56:20 +0200
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/
Received on Saturday, 11 September 2010 05:56:20 UTC