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.
This commit is contained in:
Patrick Walton 2016-02-16 11:01:23 -08:00
parent 09e987b559
commit 9b4cc41695
7 changed files with 146 additions and 115 deletions

View file

@ -5,7 +5,7 @@
//! Communication with the compositor thread.
use CompositorMsg as ConstellationMsg;
use compositor;
use compositor::{self, CompositingReason};
use euclid::point::Point2D;
use euclid::size::Size2D;
use gfx_traits::{Epoch, FrameTreeId, LayerId, LayerProperties, PaintListener};
@ -103,12 +103,12 @@ pub fn run_script_listener_thread(compositor_proxy: Box<CompositorProxy + 'stati
}
pub trait RenderListener {
fn recomposite(&mut self);
fn recomposite(&mut self, reason: CompositingReason);
}
impl RenderListener for Box<CompositorProxy + 'static> {
fn recomposite(&mut self) {
self.send(Msg::RecompositeAfterScroll);
fn recomposite(&mut self, reason: CompositingReason) {
self.send(Msg::Recomposite(reason));
}
}
@ -197,10 +197,10 @@ pub enum Msg {
LoadStart(bool, bool),
/// The load of a page has completed: (can go back, can go forward).
LoadComplete(bool, bool),
/// Indicates that the scrolling timeout with the given starting timestamp has happened and a
/// composite should happen. (See the `scrolling` module.)
ScrollTimeout(u64),
RecompositeAfterScroll,
/// We hit the delayed composition timeout. (See `delayed_composition.rs`.)
DelayedCompositionTimeout(u64),
/// Composite.
Recomposite(CompositingReason),
/// Sends an unconsumed key event back to the compositor.
KeyEvent(Key, KeyState, KeyModifiers),
/// Script has handled a touch event, and either prevented or allowed default actions.
@ -251,8 +251,8 @@ impl Debug for Msg {
Msg::SetFrameTree(..) => write!(f, "SetFrameTree"),
Msg::LoadComplete(..) => write!(f, "LoadComplete"),
Msg::LoadStart(..) => write!(f, "LoadStart"),
Msg::ScrollTimeout(..) => write!(f, "ScrollTimeout"),
Msg::RecompositeAfterScroll => write!(f, "RecompositeAfterScroll"),
Msg::DelayedCompositionTimeout(..) => write!(f, "DelayedCompositionTimeout"),
Msg::Recomposite(..) => write!(f, "Recomposite"),
Msg::KeyEvent(..) => write!(f, "KeyEvent"),
Msg::TouchEventProcessed(..) => write!(f, "TouchEventProcessed"),
Msg::SetCursor(..) => write!(f, "SetCursor"),