Builder linux-rel-wpt Build #4693

Results:

Failed shell__2

SourceStamp:

BuildSlave:

Reason:

The AnyBranchScheduler scheduler named 'servo-auto' triggered this build

Steps and Logfiles:

1. git update ( 7 secs )
   1. stdio
2. generic generic ( 0 secs )
   1. - no logs -
3. generic_1 generic_1 ( 0 secs )
   1. - no logs -
4. shell 'pkill -x ...' ( 0 secs )
   1. stdio
5. shell__1 './mach clean-nightlies ...' ( 8 secs )
   1. stdio
6. compile ran build --release --with-debug-assertions warnings ( 17 mins, 26 secs )
   1. warnings (2)
7. test ran test-wpt-failure ( 1 secs )
   1. stdio
8. test__1 ran test-wpt --release --processes 24 --always-succeed ( 13 mins, 46 secs )
   1. - no logs -
9. shell__2 './mach filter-intermittents ...' failed ( 0 secs )
   1. stdio
10. test__2 ran test-wpt --release --binary-arg=--multiprocess --processes 24 eventsource ( 11 secs )
    1. stdio
    2. wpt-mp-errorsummary.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. bors-servo

   lbergstrom+borsohnoyoudont@mozilla.com

Timing:

All Changes:

:

1. Change #52018

   Category	None
   Changed by	bors-servo <lbergstrom+borsohnoyoudont@mozilla.com>
   Changed at	Mon 19 Jun 2017 21:48:36
   Repository	https://github.com/servo/servo
   Project	servo/servo
   Branch	auto
   Revision	d150e48c3ed432dd58e578fe167477475d0478f5

   Comments

   Auto merge of #17398 - glennw:opt-composite, r=pcwalton
   
   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 -->

   Changed files

   • components/compositing/compositor.rs
   • components/compositing/compositor_thread.rs
   • components/compositing/delayed_composition.rs
   • components/compositing/lib.rs
   • components/compositing/windowing.rs
   • ports/glutin/window.rs