compositor worker: Use a WebThread for the compositor thread.

components/scheduler/child/webthread_impl_for_worker_scheduler.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_CHILD_WEBTHREAD_IMPL_FOR_WORKER_SCHEDULER_H_
 #define COMPONENTS_SCHEDULER_CHILD_WEBTHREAD_IMPL_FOR_WORKER_SCHEDULER_H_
 
 #include "base/threading/thread.h"
 #include "components/scheduler/base/task_queue_manager.h"
 #include "components/scheduler/child/webthread_base.h"
@@ skipping 15 matching lines @@
 
 class SCHEDULER_EXPORT WebThreadImplForWorkerScheduler
     : public WebThreadBase,
       public base::MessageLoop::DestructionObserver {
  public:
   explicit WebThreadImplForWorkerScheduler(const char* name);
   WebThreadImplForWorkerScheduler(const char* name,
                                   base::Thread::Options options);
   ~WebThreadImplForWorkerScheduler() override;
 
+  void Init();
+
   // blink::WebThread implementation.
   blink::WebScheduler* scheduler() const override;
   blink::PlatformThreadId threadId() const override;
   blink::WebTaskRunner* taskRunner() override;
 
   // WebThreadBase implementation.
   base::SingleThreadTaskRunner* TaskRunner() const override;
   scheduler::SingleThreadIdleTaskRunner* IdleTaskRunner() const override;
 
   // base::MessageLoop::DestructionObserver implementation.
   void WillDestroyCurrentMessageLoop() override;
 
  private:
+  // Returns whether the base::Thread's task-runner should be used as the
+  // default task runner (returns true), or the default task runner from the
+  // scheduler should be used instead (returns false). The default behaviour is
+  // to use the scheduler's default task runner.
+  virtual bool UseThreadTaskRunnerAsDefault() const;

[Sami, 2016/01/13 17:17:05]

This is a dangerous API because tasks will run in a different order depending on
which task queue they end up using, which can cause hard-to-diagnose breakage.
Could we instead try to find out what part of the scheduler code was responsible
for the regression and optimize that? I wouldn't expect the worker scheduler to
have that much overhead compared to a plain message loop -- but I might be wrong
since it's been a while since we last measured this.

[sadrul, 2016/01/13 18:29:32]

Indeed, that's what I was worried about. A different implementation of
WorkerScheduler should avoid that from happening, right? I have implemented that
in the latest patchset (it now depends on
https://codereview.chromium.org/1585723002/).
It's actually not clear exactly what is causing the regression. As you say,
WorkerSchedulerImpl doesn't do a whole lot. It does install its own task runner
on the thread, and that seems sufficient to trigger the regression. I am not
familiar with this enough to understand how to go about finding the code
responsible for the regression. Any advice? And in the meantime, would it be
acceptable to have a CompositorWorkerScheduler implementation for
WorkerScheduler (see latest patchset)?

+
   void AddTaskObserverInternal(
       base::MessageLoop::TaskObserver* observer) override;
   void RemoveTaskObserverInternal(
       base::MessageLoop::TaskObserver* observer) override;
 
   void InitOnThread(base::WaitableEvent* completion);
   void RestoreTaskRunnerOnThread(base::WaitableEvent* completion);
 
   scoped_ptr<base::Thread> thread_;
   scoped_ptr<scheduler::WorkerScheduler> worker_scheduler_;
   scoped_ptr<scheduler::WebSchedulerImpl> web_scheduler_;
   scoped_refptr<base::SingleThreadTaskRunner> thread_task_runner_;
   scoped_refptr<base::SingleThreadTaskRunner> task_runner_;
   scoped_refptr<scheduler::SingleThreadIdleTaskRunner> idle_task_runner_;
   scoped_refptr<SchedulerTqmDelegate> task_runner_delegate_;
   scoped_ptr<WebTaskRunnerImpl> web_task_runner_;
 };
 
 }  // namespace scheduler
 
 #endif  // COMPONENTS_SCHEDULER_CHILD_WEBTHREAD_IMPL_FOR_WORKER_SCHEDULER_H_