diff options
| author |  mtklein <mtklein@chromium.org> | 2014-10-27 10:27:10 -0700 |
|---|---|---|
| committer |  Commit bot <commit-bot@chromium.org> | 2014-10-27 10:27:10 -0700 |
| commit | 4477c3c0e6eb064772aefe8737425cd1c2ce557f (patch) | |
| tree | e841aeb0174e7ddc621f0b5dca88592e8c37d975 /tests/PictureTest.cpp | |
| parent | 5e44b00392e791088b693a0b462b107b0b5a91ba (diff) | |
Cut down SkBBH API more.
- The expected case is now a single bulk-load insert() call instead of N;
- reserve() and flushDeferredInserts() can fold into insert() now;
- SkBBH subclasses may take ownership of the bounds
This appears to be a performance no-op on both my Mac and N5. I guess
even the simplest indirect branch predictor ("same as last time") can predict
the repeated virtual calls to SkBBH::insert() perfectly.
BUG=skia:
Review URL: https://codereview.chromium.org/670213002
Diffstat (limited to 'tests/PictureTest.cpp')
| -rw-r--r-- | tests/PictureTest.cpp | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/tests/PictureTest.cpp b/tests/PictureTest.cpp index 7546a5d5be..fa4dc10142 100644 --- a/tests/PictureTest.cpp +++ b/tests/PictureTest.cpp @@ -1869,7 +1869,7 @@ struct CountingBBH : public SkBBoxHierarchy { this->searchCalls++; } - virtual void insert(unsigned opIndex, const SkRect& bounds, bool defer) SK_OVERRIDE {} + virtual void insert(SkAutoTMalloc<SkRect>*, int) SK_OVERRIDE {} }; class SpoonFedBBHFactory : public SkBBHFactory { |