[whatwg] VIDEO Timeupdate event frequency.

[Tab Atkins Jr.]

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
> usage.

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,
newframecallback)?

~TJ