Cut down SkBBH API more.
authormtklein <mtklein@chromium.org>
Mon, 27 Oct 2014 17:27:10 +0000 (10:27 -0700)
committerCommit bot <commit-bot@chromium.org>
Mon, 27 Oct 2014 17:27:10 +0000 (10:27 -0700)
commit4477c3c0e6eb064772aefe8737425cd1c2ce557f
treee841aeb0174e7ddc621f0b5dca88592e8c37d975
parent5e44b00392e791088b693a0b462b107b0b5a91ba
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
12 files changed:
bench/RTreeBench.cpp
src/core/SkBBoxHierarchy.h
src/core/SkRTree.cpp
src/core/SkRTree.h
src/core/SkRecordDraw.cpp
src/core/SkTileGrid.cpp
src/core/SkTileGrid.h
tests/PictureTest.cpp
tests/RTreeTest.cpp
tests/RecordDrawTest.cpp
tests/RecordReplaceDrawTest.cpp
tests/TileGridTest.cpp