Optimize for TouchStart responsiveness

components/scheduler/renderer/user_model.h

+// Copyright 2015 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.
+
+#ifndef COMPONENTS_SCHEDULER_RENDERER_USER_MODEL_H_
+#define COMPONENTS_SCHEDULER_RENDERER_USER_MODEL_H_
+
+#include "base/macros.h"
+#include "base/trace_event/trace_event.h"
+#include "base/trace_event/trace_event_argument.h"
+#include "components/scheduler/renderer/renderer_scheduler.h"
+#include "components/scheduler/scheduler_export.h"
+#include "third_party/WebKit/public/web/WebInputEvent.h"
+
+namespace scheduler {
+
+class SCHEDULER_EXPORT UserModel {
+ public:
+  UserModel();
+  ~UserModel();
+
+  // Tells us that the system processed an input event. Called by the compositor
+  // (impl) thread.  Note it's expected that every call to
+  // DidHandleInputEventOnCompositorThread where |event_state| is
+  // EVENT_FORWARDED_TO_MAIN_THREAD will be followed by a corresponding call
+  // to DidHandleInputEventOnMainThread.
+  void DidHandleInputEventOnCompositorThread(

[Sami, 2015/08/27 15:15:59]

This is called on the impl thread but it doesn't look like there's any locking
here? Is there a way to isolate the user model from threading somehow?

[alex clarke (OOO till 29th), 2015/09/03 10:34:25]

This class isn't by itself thread safe. However it's protected by the
AnyThread() lock inside of RendererSchedulerImpl.   

I think that's fine, but perhaps it's confusing to mention threads here? WDYT

+      blink::WebInputEvent::Type type,
+      RendererScheduler::InputEventState input_event_state,
+      const base::TimeTicks now);
+
+  // Tells us that the system processed an input event.
+  void DidHandleInputEventOnMainThread(const base::TimeTicks now);
+
+  // Returns the amount of time left in the current input escalated priority
+  // policy. Can be called from any thread.
+  base::TimeDelta TimeLeftInInputEscalatedPolicy(base::TimeTicks now) const;
+
+  // Tries to guess if a Touchstart is expected soon. Currently this is
+  // very simple, but one day I hope to do something more sophisticated here.
+  // The prediction may change after |prediction_valid_duration| has elapsed.
+  bool TouchStartExpectedSoon(RendererScheduler::UseCase use_case,

[Sami, 2015/08/27 15:15:59]

nit: Maybe IsTouchStartExpectedSoon() to highlight that this is a query and not
a statement of fact?

[alex clarke (OOO till 29th), 2015/09/03 10:34:25]

Done.

+                              const base::TimeTicks now,
+                              base::TimeDelta* prediction_valid_duration) const;
+
+  void AsValueInto(base::trace_event::TracedValue* state) const;
+
+  // The time we should stay in a priority-escalated mode after an input event.
+  static const int kPriorityEscalationAfterInputMillis = 100;
+
+  // TODO(alexclarke): Get a real number on actual data.
+  static const int kMinimumTypicalScrollDurationMillis = 500;
+
+  // We consider further input invents to be likely if the user has interacted

[Sami, 2015/08/27 15:15:59]

typo: events

[alex clarke (OOO till 29th), 2015/09/03 10:34:25]

Done.

+  // with the device in the past two seconds.
+  // TODO(alexclarke): Get a real number based on actual data.
+  static const int kExpectSubsequentInputMillis = 2000;
+
+ private:
+  int pending_main_thread_input_event_count_;

[Sami, 2015/08/27 15:15:59]

It feels like this shouldn't be part of the user model since it's really an
artifact of how input events are delivered. Do you think we could pull it out?

+  base::TimeTicks last_input_signal_time_;
+  base::TimeTicks last_touchstart_time_;
+
+  DISALLOW_COPY_AND_ASSIGN(UserModel);
+};
+
+}  // namespace scheduler
+
+#endif  // COMPONENTS_SCHEDULER_RENDERER_USER_MODEL_H_