[whatwg] VIDEO Timeupdate event frequency.
Tab Atkins Jr.
jackalmage at gmail.com
Fri Sep 10 10:49:21 PDT 2010
On Fri, Sep 10, 2010 at 10:14 AM, Simon Fraser <smfr at me.com> wrote:
> On Sep 10, 2010, at 10:07 AM, Tab Atkins Jr. wrote:
>> On Fri, Sep 10, 2010 at 9:58 AM, Simon Fraser <smfr at me.com> wrote:
>>> The problem with a 'newFrame' callback is what to do if the callback
>>> takes longer than the duration of a single frame. Does the video engine
>>> start dropping frames, or does the video lag?
>> Dropping frames would be the better solution, for all the uses I'd put
>> it to. (Or rather, dropping newFrame events.)
>>> In WebKit on Mac, video playback is hardware-accelerated, and the
>>> presentation of video frames is disconnected from the web page
>>> drawing machinery. A newFrame callback would force us to drop
>>> back into software rendering, which is significantly more CPU intensive.
>>> I don't support the general use of a 'newFrame' callback except in
>>> the context of video processing via canvas.
>> In general, video processing via canvas is going to require dropping
>> into software rendering, right? I think that's what I was hearing
>> from our dudes putting hardware-accelerated video into Chrome. So at
>> least in the case that I can see this often being put towards, you
>> don't lose anything.
> My concern would be pages registering for newFrame events just
> to do stuff like updating a controller, which will vastly increase CPU
That seems like a valid concern. So, keep timeupdate the way it is,
but look into adding something that explicitly links a canvas and a
video? Maybe something like canvas.drawVideo(video, x, y, w, h,
More information about the whatwg