tree e841aeb0174e7ddc621f0b5dca88592e8c37d975
parent 5e44b00392e791088b693a0b462b107b0b5a91ba
author mtklein <mtklein@chromium.org> 1414430830 -0700
committer Commit bot <commit-bot@chromium.org> 1414430830 -0700

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