commit 4477c3c0e6eb064772aefe8737425cd1c2ce557f
author mtklein <mtklein@chromium.org> Mon Oct 27 10:27:10 2014 -0700
committer Commit bot <commit-bot@chromium.org> Mon Oct 27 10:27:10 2014 -0700
tree e841aeb0174e7ddc621f0b5dca88592e8c37d975
parent 5e44b00392e791088b693a0b462b107b0b5a91ba

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