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

[Thomas Guilbert]

You're right, it doesn't in Chromium either (and I ran into that issue
testing it :)). I will be updating the spec over the next few days.

On Wed, Feb 5, 2020 at 5:09 PM Simon Fraser <simon.fraser at apple.com> wrote:

> > On Feb 5, 2020, at 4:52 PM, Thomas Guilbert <tguilbert at google.com>
> wrote:
> >
> > I am moving the execution of the video.rAF callbacks to be part of the
> rendering steps. This should guarantee that "changes made inside the
> callback appear at the same time as other changes in the same event loop
> cycle".
> > I don't know if there is a place within the rendering steps where it
> makes most sense for them to run. I'm planning on having them run before
> the window.rAF callbacks, but I don't know after which of the other steps
> for now.
> >
> > That being said, if you paint a 24fps <video> into a <canvas> on every
> video.rAF call, the canvas might still be 1/60th of a second behind the
> video. This happens when we miss the rendering steps after jumping back on
> the main thread, and have to wait for the next rendering steps (waiting
> doesn't really change anything though, if the callbacks were fired earlier,
> their changes would still appear later).
> >
> > Simon, does having video.rAF callbacks run as part of the rendering
> steps address some of your concerns?
>
> It does, although I still don't like the name.
>
> The spec also needs somehow trigger the "update the rendering" steps if a
> new video frame is available and there is a pending video.rAF (video
> playback alone does not trigger the rendering steps, at least in WebKit,
> for performance reasons).
>
> Simon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200205/2d957ff4/attachment.htm>