Improve decisions in compositor over when to draw a frame.#17398
Improve decisions in compositor over when to draw a frame.#17398bors-servo merged 3 commits intoservo:masterfrom
Conversation
|
r? @pcwalton I think the above comments are all correct, and this certainly results in smoother results and "correct" frame rates based on rAF, from what I've tested is. Nonetheless, changing things like this is quite subtle, and I might be missing something - so this could do with a careful look over! |
|
cc @asajeffrey and @cbrewster since I think you've been working in this area and may have comments. |
|
Fixed tidy error. |
|
@bors-servo: r+ |
|
📌 Commit 36829da has been approved by |
Improve decisions in compositor over when to draw a frame. This patch fixes a couple of issues in the compositor: 1) Remove the delayed composition code. Previously, this would schedule a composite for 12ms in the future. This doesn't really make any sense with WR. There's no point in doing a composite unless WR has provided a new frame to be drawn. This fixes issues in several benchmarks where we were doing multiple composite / renders per rAF, which is a waste of CPU time. This *does* make the framerate slower in some cases (such as a slow rAF callback) but it's more correct - otherwise we were just compositing the same frame multiple times for no real benefit. 2) Inform the window of the current animation state of the compositor. Specifically, if an animation (or rAF) is currently active, the window system switches to use event polling, and does not block on the OS-level event loop. In the case of active animation, we just assume that we want to be running as the vsync interval and not blocking. This means the compositor thread only sleeps on vsync during animation, which reduces OS scheduling and results in much smoother animation. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17398) <!-- Reviewable:end -->
|
💔 Test failed - linux-rel-wpt |
|
This patch fixes a couple of issues in the compositor: 1) Remove the delayed composition code. Previously, this would schedule a composite for 12ms in the future. This doesn't really make any sense with WR. There's no point in doing a composite unless WR has provided a new frame to be drawn. This fixes issues in several benchmarks where we were doing multiple composite / renders per rAF, which is a waste of CPU time. This *does* make the framerate slower in some cases (such as a slow rAF callback) but it's more correct - otherwise we were just compositing the same frame multiple times for no real benefit. 2) Inform the window of the current animation state of the compositor. Specifically, if an animation (or rAF) is currently active, the window system switches to use event polling, and does not block on the OS-level event loop. In the case of active animation, we just assume that we want to be running as the vsync interval and not blocking. This means the compositor thread only sleeps on vsync during animation, which reduces OS scheduling and results in much smoother animation.
yet considered spurious force a reflow / composite / animation tick cycle.
|
Removing the delayed compositor timer exposed a bug in how we handle rAF callbacks that don't mutate the DOM. Added a second commit to handle that. r? @jdm |
|
(or anyone else who knows the DOM code well enough to review that). |
|
@bors-servo: r+ |
|
📌 Commit 6c9e305 has been approved by |
Improve decisions in compositor over when to draw a frame. This patch fixes a couple of issues in the compositor: 1) Remove the delayed composition code. Previously, this would schedule a composite for 12ms in the future. This doesn't really make any sense with WR. There's no point in doing a composite unless WR has provided a new frame to be drawn. This fixes issues in several benchmarks where we were doing multiple composite / renders per rAF, which is a waste of CPU time. This *does* make the framerate slower in some cases (such as a slow rAF callback) but it's more correct - otherwise we were just compositing the same frame multiple times for no real benefit. 2) Inform the window of the current animation state of the compositor. Specifically, if an animation (or rAF) is currently active, the window system switches to use event polling, and does not block on the OS-level event loop. In the case of active animation, we just assume that we want to be running as the vsync interval and not blocking. This means the compositor thread only sleeps on vsync during animation, which reduces OS scheduling and results in much smoother animation. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17398) <!-- Reviewable:end -->
|
💔 Test failed - linux-rel-wpt |
|
@bors-servo r- I'm seeing a few demos not animating correctly locally. I need to investigate more to see if it's related to this change. |
This fixes another rAF bug, that is being exposed by the previous two commits. Previously, the fake timer callback would only be set if we were being called from a non-rAF event handler. Now, if we're in fake / spurious mode, unconditionally set the one shot timer. Otherwise, notify the compositor that animations are present if we're not currently in a rAF callback.
|
Added a follow up commit that addresses an issue I ran into. r? @jdm |
|
@bors-servo: r+ |
|
📌 Commit cbeb181 has been approved by |
Improve decisions in compositor over when to draw a frame. This patch fixes a couple of issues in the compositor: 1) Remove the delayed composition code. Previously, this would schedule a composite for 12ms in the future. This doesn't really make any sense with WR. There's no point in doing a composite unless WR has provided a new frame to be drawn. This fixes issues in several benchmarks where we were doing multiple composite / renders per rAF, which is a waste of CPU time. This *does* make the framerate slower in some cases (such as a slow rAF callback) but it's more correct - otherwise we were just compositing the same frame multiple times for no real benefit. 2) Inform the window of the current animation state of the compositor. Specifically, if an animation (or rAF) is currently active, the window system switches to use event polling, and does not block on the OS-level event loop. In the case of active animation, we just assume that we want to be running as the vsync interval and not blocking. This means the compositor thread only sleeps on vsync during animation, which reduces OS scheduling and results in much smoother animation. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17398) <!-- Reviewable:end -->
|
💔 Test failed - mac-rel-wpt4 |
|
@bors-servo: retry
|
Improve decisions in compositor over when to draw a frame. This patch fixes a couple of issues in the compositor: 1) Remove the delayed composition code. Previously, this would schedule a composite for 12ms in the future. This doesn't really make any sense with WR. There's no point in doing a composite unless WR has provided a new frame to be drawn. This fixes issues in several benchmarks where we were doing multiple composite / renders per rAF, which is a waste of CPU time. This *does* make the framerate slower in some cases (such as a slow rAF callback) but it's more correct - otherwise we were just compositing the same frame multiple times for no real benefit. 2) Inform the window of the current animation state of the compositor. Specifically, if an animation (or rAF) is currently active, the window system switches to use event polling, and does not block on the OS-level event loop. In the case of active animation, we just assume that we want to be running as the vsync interval and not blocking. This means the compositor thread only sleeps on vsync during animation, which reduces OS scheduling and results in much smoother animation. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17398) <!-- Reviewable:end -->
|
☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css1, mac-rel-css2, mac-rel-wpt1, mac-rel-wpt2, mac-rel-wpt3, mac-rel-wpt4, windows-msvc-dev |


This patch fixes a couple of issues in the compositor:
Remove the delayed composition code. Previously, this would schedule
a composite for 12ms in the future. This doesn't really make any sense
with WR. There's no point in doing a composite unless WR has provided
a new frame to be drawn. This fixes issues in several benchmarks where
we were doing multiple composite / renders per rAF, which is a waste
of CPU time. This does make the framerate slower in some cases (such
as a slow rAF callback) but it's more correct - otherwise we were just
compositing the same frame multiple times for no real benefit.
Inform the window of the current animation state of the compositor.
Specifically, if an animation (or rAF) is currently active, the
window system switches to use event polling, and does not block on
the OS-level event loop. In the case of active animation, we just
assume that we want to be running as the vsync interval and not
blocking. This means the compositor thread only sleeps on vsync
during animation, which reduces OS scheduling and results in much
smoother animation.
This change is