[webkit-dev] Position on emerging standard: video.requestAnimationFrame()

Ken Russell kbr at google.com
Mon Feb 3 11:25:55 PST 2020

The name "requestAnimationFrame" was chosen mainly to achieve parity with
the AnimationFrameProvider mixin, which now provides the same animation
facility to the main thread and dedicated workers:

It offers a nice symmetry with other JavaScript-driven animations.


On Mon, Feb 3, 2020 at 6:58 AM Philip Jägenstedt <foolip at chromium.org>

> Hi Simon,
> Naming is hard as usual and was discussed on
> https://github.com/w3ctag/design-reviews/issues/429, where you've already
> commented.
> Is there a pair of names that you think would work better
> here? onFrameAvailable() would IMHO be quite unidiomatic, the web platform
> doesn't have any other onFoo() methods, and what would the "cancel" variant
> be called?
> Can you file an issue in https://github.com/WICG/video-raf/issues if you
> see a good alternative?
> Also curious if +Eric Carlson <eric.carlson at apple.com> has any feedback
> on this?
> On Wed, Jan 22, 2020 at 10:49 PM Simon Fraser <simon.fraser at apple.com>
> wrote:
>> On Jan 21, 2020, at 5:27 PM, Thomas Guilbert <tguilbert at google.com>
>> wrote:
>> The idea was to reuse an API name that developers are already
>> familiar with, in a similar context. The name is also being used in
>> XRSession (
>> https://developer.mozilla.org/en-US/docs/Web/API/XRSession/requestAnimationFrame),
>> and in OffscreenCanvas (or technically DedicatedWorkerGlobalScope). The AnimationFrameProvider
>> mixin
>> <https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#animationframeprovider> could
>> also be updated so HTMLVideoElement can extend it.
>> Yes, this isn't formally spec'ed out, but it will be. For now, they are
>> added to the task queue and run like any other task. So, going off the spec
>> you linked, I think this would be "5) Perform oldestTask's step"  and not
>> "10) Rendering: [...] 11. Foreach document run animation frame callbacks
>> for that Document".
>> I would expect something that's called "requestAnimationFrame" to only
>> fire in the "update the rendering" steps; requestAnimationFrame is a
>> "before rendering" callback. So firing a callback with the same name at
>> other times seems like it will lead to author confusion.
>> The author's expectation should be that any content/style changes they
>> make inside a requestAnimationFrame callback will appear on-screen in the
>> same frame as other changes in the same event loop cycle, and that
>> requestAnimationFrame won't be called more often than is necessary to
>> update the screen at the appropriate frame rate.
>> Simon
>> On Tue, Jan 21, 2020 at 1:01 PM Simon Fraser <simon.fraser at apple.com>
>> wrote:
>>> On Jan 21, 2020, at 12:37 PM, Thomas Guilbert <tguilbert at google.com>
>>> wrote:
>>> Hello,
>>> I'm reaching out to see if webkit would like to weigh in on the following proposal:https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691
>>> The HTMLVideoElement.requestAnimationFrame() API allows web developers to be notified when a video frame has been presented for composition, and provides metadata for that frame.
>>> If you want to try it out, a prototype is available in Chromium Dev,
>>> behind the enable-experimental-web-platform-features flag.
>>> This is not official feedback, but I have some issues with the proposal.
>>> First, the name is confusing. It sounds like you're requesting a frame
>>> from the video, but it's really a "frame available" callback. Why not call
>>> it onFrameAvailable()?
>>> Second, its interaction with normal requestAnimationFrame() and the HTML
>>> event loop needs to be better defined. Where in in the
>>> https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model do
>>> these callbacks fire?
>>> Simon
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200203/881ee084/attachment-0004.htm>

More information about the webkit-dev mailing list