Use TaskScheduler instead of WorkerPool in navigation_entry_screenshot_manager.cc.

content/browser/frame_host/navigation_entry_screenshot_manager.cc

 // Copyright 2013 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 "content/browser/frame_host/navigation_entry_screenshot_manager.h"
 
 #include "base/command_line.h"
 #include "base/macros.h"
-#include "base/threading/worker_pool.h"
+#include "base/task_scheduler/post_task.h"
 #include "content/browser/frame_host/navigation_controller_impl.h"
 #include "content/browser/frame_host/navigation_entry_impl.h"
 #include "content/browser/renderer_host/render_view_host_impl.h"
 #include "content/public/browser/overscroll_configuration.h"
 #include "content/public/browser/render_widget_host.h"
 #include "content/public/browser/render_widget_host_view.h"
 #include "content/public/common/content_switches.h"
 #include "ui/gfx/codec/png_codec.h"
 
 namespace {
 
 // Minimum delay between taking screenshots.
 const int kMinScreenshotIntervalMS = 1000;
 
 }
 
 namespace content {
 
 // Encodes the A8 SkBitmap to grayscale PNG in a worker thread.
 class ScreenshotData : public base::RefCountedThreadSafe<ScreenshotData> {
  public:
   ScreenshotData() {
   }
 
   void EncodeScreenshot(const SkBitmap& bitmap, base::Closure callback) {
-    if (!base::WorkerPool::PostTaskAndReply(FROM_HERE,
-            base::Bind(&ScreenshotData::EncodeOnWorker,
-                       this,
-                       bitmap),
-            callback,
-            true)) {

[alexmos, 2017/01/03 19:19:06]

Is there's an equivalent to task_is_slow in TaskScheduler?  I'm not too familiar
with how important this is -- is it ok to lose it?

[fdoray, 2017/01/04 00:27:09]

|task_is_slow| is ignored by WorkerPool and developers told us that they don't
like the fact that there are no clear guidelines to determine whether a task is
slow.

There is no equivalent to |task_is_slow| in TaskScheduler. However, there is a
MayBlock() trait for tasks that block (e.g. synchronously read a file from
disk).  When a MayBlock() task takes a long time to run, TaskScheduler may
decide to create a new thread (note that TaskScheduler dynamically determines
whether a task takes a long time to run).

FWICT, ScreenshotData::EncodeOnWorker is CPU-bound. Therefore, it should not be
posted with MayBlock().

[alexmos, 2017/01/04 01:00:08]

At least on Windows, it seems to be used to add WT_EXECUTELONGFUNCTION to
QueueUserWorkItem flags, see 
https://cs.chromium.org/chromium/src/base/threading/worker_pool_win.cc?l=46

Losing that was mostly why I was curious about this.
Acknowledged.

[fdoray, 2017/01/04 02:13:15]

Our experiments show that this flag is ignored on newer versions of Windows (it
was used on XP).

-      callback.Run();
-    }
+    base::PostTaskWithTraitsAndReply(
+        FROM_HERE, base::TaskTraits().WithShutdownBehavior(
+                       base::TaskShutdownBehavior::CONTINUE_ON_SHUTDOWN),
+        base::Bind(&ScreenshotData::EncodeOnWorker, this, bitmap), callback);
   }
 
   scoped_refptr<base::RefCountedBytes> data() const { return data_; }
 
  private:
   friend class base::RefCountedThreadSafe<ScreenshotData>;
   virtual ~ScreenshotData() {
   }
 
   void EncodeOnWorker(const SkBitmap& bitmap) {
@@ skipping 194 matching lines @@
     NavigationEntryImpl* entry = owner_->GetEntryAtIndex(forward);
     if (ClearScreenshot(entry))
       --screenshot_count;
     ++forward;
   }
   CHECK_GE(screenshot_count, 0);
   CHECK_LE(screenshot_count, kMaxScreenshots);
 }
 
 }  // namespace content