New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compositor: Improve the way we wait for frames #31523
compositor: Improve the way we wait for frames #31523
Conversation
🔨 Triggering try run (#8174165456) for Linux WPT |
|
In the newest version of WebRender it will be harder to make the distinction between frame queued for scrolling and other kinds of pending frames. This change makes it so that we queue frames for both kinds of changes the same way and keeps a counting of pending frames. This is conceptually a lot simpler. In addition, do queue a composite even when recomposite isn't necessary for a WebRender frame when there are active requestAnimationFrame callbacks. Doing a composite is what triggers the callbacks to actually run in the script thread! I believe this was a bug, but the WebRender upgrade made it much more obvious. These changes are in preparation for the WebRender upgrade.
c4122ea
to
4380e77
Compare
🔨 Triggering try run (#8175329291) for Linux WPT |
Test results for linux-wpt-layout-2020 from try job (#8175329291): Flaky unexpected result (18)
Stable unexpected results that are known to be intermittent (16)
|
✨ Try run (#8175329291) succeeded. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove spurious println
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for walking me through it. It looks good
In the newest version of WebRender it will be harder to make the
distinction between frame queued for scrolling and other kinds of
pending frames. This change makes it so that we queue frames for both
kinds of changes the same way and keeps a counting of pending frames.
This is conceptually a lot simpler.
In addition, do queue a composite even when recomposite isn't necessary
for a WebRender frame when there are active requestAnimationFrame
callbacks. Doing a composite is what triggers the callbacks to actually
run in the script thread! I believe this was a bug, but the WebRender
upgrade made it much more obvious.
These changes are in preparation for the WebRender upgrade.
./mach build -d
does not report any errors./mach test-tidy
does not report any errors