Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upcompositing: Stop compositing unnecessarily after each animation frame. #9663
Conversation
highfive
commented
Feb 16, 2016
|
|
| timestamp = this_timestamp; | ||
| break | ||
| } | ||
| _ => break, |
This comment has been minimized.
This comment has been minimized.
samlh
Feb 16, 2016
Contributor
Should this have a case for exit? e.g.
Ok(ToDelayedCompositionTimerMsg::Exit) => break 'outer,
|
|
|
@pcwalton This looks good to me once the comment / question is resolved, will need a rebase though. |
Instead, schedule a delayed composite after each frame of an animation. The previous code would cause jank, because the following sequence frequently occurred: 1. The page uses `requestAnimationFrame()` to request a frame. 2. The compositor receives the message, schedules a composite, dispatches the rAF message to the script thread, composites, and goes to sleep waiting for vblank (frame 1). 3. The script makes a change and sends it through the pipeline. Eventually it gets painted and is sent to the compositor, but the compositor is sleeping. 4. The compositor wakes up, sees the new painted content, page flips, and goes to sleep (frame 2). Repeat from step 1. The problem is that we have two composition frames, not just one. This halves Web apps' framerate! This commit fixes the problem by scheduling the composite in step 2 to 12 ms in the future. We already have this delayed-composition functionality in the form of the scrolling timer, which I repurposed and renamed to the "delayed composition timer" for this task. This change gives the page 12 ms to prepare the frame, which seems to usually be enough, especially with WebRender. Note that simply removing the scheduled composite after rAF is not the correct solution. If this is done, then pages that call rAF and don't modify the page won't receive future rAFs, since the compositor will be sleeping and won't be notified of vblank. Fixes a bunch of jank in browser.html. The remaining jank seems to be a problem with browser.html itself.
pcwalton
force-pushed the
pcwalton:browser-html-jank-fix
branch
from
a05ab3c
to
9b4cc41
|
@bors-servo: r=glennw |
|
|
bors-servo
added a commit
that referenced
this pull request
Feb 24, 2016
compositing: Stop compositing unnecessarily after each animation frame. Instead, schedule a delayed composite after each frame of an animation. The previous code would cause jank, because the following sequence frequently occurred: 1. The page uses `requestAnimationFrame()` to request a frame. 2. The compositor receives the message, schedules a composite, dispatches the rAF message to the script thread, composites, and goes to sleep waiting for vblank (frame 1). 3. The script makes a change and sends it through the pipeline. Eventually it gets painted and is sent to the compositor, but the compositor is sleeping. 4. The compositor wakes up, sees the new painted content, page flips, and goes to sleep (frame 2). Repeat from step 1. The problem is that we have two composition frames, not just one. This halves Web apps' framerate! This commit fixes the problem by scheduling the composite in step 2 to 12 ms in the future. We already have this delayed-composition functionality in the form of the scrolling timer, which I repurposed and renamed to the "delayed composition timer" for this task. This change gives the page 12 ms to prepare the frame, which seems to usually be enough, especially with WebRender. Note that simply removing the scheduled composite after rAF is not the correct solution. If this is done, then pages that call rAF and don't modify the page won't receive future rAFs, since the compositor will be sleeping and won't be notified of vblank. Fixes a bunch of jank in browser.html. The remaining jank seems to be a problem with browser.html itself. r? @glennw <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9663) <!-- Reviewable:end -->
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
pcwalton commentedFeb 16, 2016
Instead, schedule a delayed composite after each frame of an animation.
The previous code would cause jank, because the following sequence
frequently occurred:
requestAnimationFrame()to request a frame.dispatches the rAF message to the script thread, composites, and goes to
sleep waiting for vblank (frame 1).
Eventually it gets painted and is sent to the compositor, but the
compositor is sleeping.
and goes to sleep (frame 2). Repeat from step 1.
The problem is that we have two composition frames, not just one. This
halves Web apps' framerate!
This commit fixes the problem by scheduling the composite in step 2 to
12 ms in the future. We already have this delayed-composition
functionality in the form of the scrolling timer, which I repurposed and
renamed to the "delayed composition timer" for this task. This change
gives the page 12 ms to prepare the frame, which seems to usually be
enough, especially with WebRender.
Note that simply removing the scheduled composite after rAF is not the
correct solution. If this is done, then pages that call rAF and don't
modify the page won't receive future rAFs, since the compositor will be
sleeping and won't be notified of vblank.
Fixes a bunch of jank in browser.html. The remaining jank seems to be a
problem with browser.html itself.
r? @glennw