Optimize for TouchStart responsiveness

cc/trees/thread_proxy.cc

 // Copyright 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "cc/trees/thread_proxy.h"
 
 #include <algorithm>
 #include <string>
 
 #include "base/auto_reset.h"
@@ skipping 1162 matching lines @@
       impl().input_throttled_until_commit) {
     // Once we enter NEW_CONTENTS_TAKES_PRIORITY mode, visible tiles on active
     // tree might be freed. We need to set RequiresHighResToDraw to ensure that
     // high res tiles will be required to activate pending tree.
     impl().layer_tree_host_impl->SetRequiresHighResToDraw();
     priority = NEW_CONTENT_TAKES_PRIORITY;
   }
 
   impl().layer_tree_host_impl->SetTreePriority(priority);
 
-  // Only put the scheduler in impl latency prioritization mode if we don't
-  // have a scroll listener. This gives the scroll listener a better chance of
-  // handling scroll updates within the same frame. The tree itself is still
-  // kept in prefer smoothness mode to allow checkerboarding.
-  impl().scheduler->SetImplLatencyTakesPriority(
-      priority == SMOOTHNESS_TAKES_PRIORITY &&
-      !impl().layer_tree_host_impl->scroll_affects_scroll_handler());
+  // Put the scheduler in impl latency prioritization mode if there's no new

[Sami, 2015/08/26 13:38:01]

nit: the comment isn't entirely accurate (we might still have new content but
we're just not prioritizing it).

Could you split this change into its own patch since I think it'd be useful by
itself and might trigger interesting things on the perf bots? Mainly I'm
wondering what this will do to the scroll update metrics and how much we should
care about that.

One thing we could try would be to ship both bits (BeginMainFrame is critical, a
scroll handler is being targeted) separately and then prioritizing scrolling if
it looks like it can do the job fast enough. WDYT?

[alex clarke (OOO till 29th), 2015/08/27 12:02:51]

As discussed offline I'm going to do this in a separate patch.

+  // content. This signal is also used by the renderer scheduler to work out if
+  // compositor tasks are on the critical path or not.
+  impl().scheduler->SetImplLatencyTakesPriority(priority !=
+                                                NEW_CONTENT_TAKES_PRIORITY);
 
   // Notify the the client of this compositor via the output surface.
   // TODO(epenner): Route this to compositor-thread instead of output-surface
   // after GTFO refactor of compositor-thread (http://crbug/170828).
   if (impl().layer_tree_host_impl->output_surface()) {
     impl()
         .layer_tree_host_impl->output_surface()
         ->UpdateSmoothnessTakesPriority(priority == SMOOTHNESS_TAKES_PRIORITY);
   }
 }
@@ skipping 54 matching lines @@
 
 void ThreadProxy::PostFrameTimingEvents(
     scoped_ptr<FrameTimingTracker::CompositeTimingSet> composite_events,
     scoped_ptr<FrameTimingTracker::MainFrameTimingSet> main_frame_events) {
   DCHECK(IsMainThread());
   layer_tree_host()->RecordFrameTimingEvents(composite_events.Pass(),
                                              main_frame_events.Pass());
 }
 
 }  // namespace cc