aboutsummaryrefslogtreecommitdiffstats
path: root/components/layout/layout_thread.rs
diff options
context:
space:
mode:
authorbors-servo <lbergstrom+bors@mozilla.com>2016-02-25 03:56:02 +0530
committerbors-servo <lbergstrom+bors@mozilla.com>2016-02-25 03:56:02 +0530
commit9d47b344d9d0cf6faa3430bb32bdb4ba3eb11cf7 (patch)
tree203738cd28b889ce688f2e5481283416e757583b /components/layout/layout_thread.rs
parent7f8c34ce8ed6e5758d2723a2c736107f9765aa24 (diff)
parent9b4cc416954ac550788f3cd82f0016d74d4995ea (diff)
downloadservo-9d47b344d9d0cf6faa3430bb32bdb4ba3eb11cf7.tar.gz
servo-9d47b344d9d0cf6faa3430bb32bdb4ba3eb11cf7.zip
Auto merge of #9663 - pcwalton:browser-html-jank-fix, r=glennw
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 -->
Diffstat (limited to 'components/layout/layout_thread.rs')
-rw-r--r--components/layout/layout_thread.rs4
1 files changed, 2 insertions, 2 deletions
diff --git a/components/layout/layout_thread.rs b/components/layout/layout_thread.rs
index b574e2d62fd..999a979f028 100644
--- a/components/layout/layout_thread.rs
+++ b/components/layout/layout_thread.rs
@@ -1196,8 +1196,8 @@ impl LayoutThread {
self.tick_animations(&mut rw_data);
self.script_chan
- .send(ConstellationControlMsg::TickAllAnimations(self.id))
- .unwrap();
+ .send(ConstellationControlMsg::TickAllAnimations(self.id))
+ .unwrap();
}
pub fn tick_animations(&mut self, rw_data: &mut LayoutThreadData) {