Let SampleApp provide the thread pool

Otherwise, creating a new thread pool each frame could be a major bottleneck.
Somehow, creating new thread pool each frame is good for measuring FPS, so
that behavior is maintained when fMeasureFPS is true. I'm still doing
experiments with my own schedulers. Once they get more stable, I'll probably
apply their changes to the SkExecutor.

Bug: skia:
Change-Id: Iead96034e0d0abdebb5069dec41215990f71f693
Reviewed-on: https://skia-review.googlesource.com/41845
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>

1 files changed, 4 insertions, 1 deletions

diff --git a/samplecode/SampleApp.cpp b/samplecode/SampleApp.cpp
index faceea47b1..fcc7feec96 100644
--- a/samplecode/SampleApp.cpp
+++ b/samplecode/SampleApp.cpp
@@ -1096,7 +1096,10 @@ void SampleWindow::draw(SkCanvas* canvas) {
     std::unique_ptr<SkThreadedBMPDevice> tDev;
     std::unique_ptr<SkCanvas> tCanvas;
     if (fTiles > 0 && fDeviceType == kRaster_DeviceType) {
-        tDev.reset(new SkThreadedBMPDevice(this->getBitmap(), fTiles, fThreads));
+        // Temporary hack: let the device create/destroy the thread pool between each frame somehow
+        // makes it faster when we draw the same path 100 times when fMeasureFPS is true.
+        SkExecutor* executor = fMeasureFPS ? nullptr : fExecutor.get();
+        tDev.reset(new SkThreadedBMPDevice(this->getBitmap(), fTiles, fThreads, executor));
         tCanvas.reset(new SkCanvas(tDev.get()));
         canvas = tCanvas.get();
     }