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

1 files changed, 6 insertions, 3 deletions

diff --git a/tests/RecordDrawTest.cpp b/tests/RecordDrawTest.cpp
index 43d4f6068b..6105c00f7f 100644
--- a/tests/RecordDrawTest.cpp
+++ b/tests/RecordDrawTest.cpp
@@ -100,9 +100,12 @@ DEF_TEST(RecordDraw_SetMatrixClobber, r) {
 }
 
 struct TestBBH : public SkBBoxHierarchy {
-    virtual void insert(unsigned opIndex, const SkRect& bounds, bool defer) SK_OVERRIDE {
-        Entry e = { opIndex, bounds };
-        fEntries.push(e);
+    virtual void insert(SkAutoTMalloc<SkRect>* boundsArray, int N) SK_OVERRIDE {
+        fEntries.setCount(N);
+        for (int i = 0; i < N; i++) {
+            Entry e = { (unsigned)i, (*boundsArray)[i] };
+            fEntries[i] = e;
+        }
     }
 
     virtual void search(const SkRect& query, SkTDArray<unsigned>* results) const SK_OVERRIDE {}