Re: Why does media capture require a browser?

Jim Barnett wrote:
> That makes sense.  If someone has a video processing application that
> can’t afford dropped frames, it cannot be real time.  They will have to
> call record, save the encoded  file, and postprocess.  For real time
> applications, they will poll with takeFrame.

I dislike the polling style of APIs because there's an implicit 
assumption that the processing will _never_ be faster than the rate at 
which the data is produced. For some video sizes and some processing 
loads, that's already not true today, and it will become less so in the 
future (as CPU/GPU power becomes more plentiful, and video framerates 
stay roughly the same). I think a model like requestAnimationFrame() is 
far cleaner. It supports throttling when the UA is overloaded (or when a 
tab is in the background, etc.), but will never trigger more often than 
actual data is produced.

Received on Tuesday, 26 February 2013 03:45:52 UTC