> On Feb 5, 2020, at 4:52 PM, Thomas Guilbert <tguilb...@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 


webkit-dev mailing list

Reply via email to