> 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 reasons). Simon _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
