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, 2 insertions, 2 deletions

diff --git a/tests/RecordReplaceDrawTest.cpp b/tests/RecordReplaceDrawTest.cpp
index 6ce45e43d5..5d407387da 100644
--- a/tests/RecordReplaceDrawTest.cpp
+++ b/tests/RecordReplaceDrawTest.cpp
@@ -103,7 +103,7 @@ void test_replacements(skiatest::Reporter* r, bool useBBH) {
     {
         SkRTreeFactory bbhFactory;
         SkPictureRecorder recorder;
-        SkCanvas* canvas = recorder.beginRecording(SkIntToScalar(kWidth), SkIntToScalar(kHeight), 
+        SkCanvas* canvas = recorder.beginRecording(SkIntToScalar(kWidth), SkIntToScalar(kHeight),
                                                    useBBH ? &bbhFactory : NULL);
 
         SkAutoTDelete<SkPaint> paint(SkNEW(SkPaint));
@@ -116,7 +116,7 @@ void test_replacements(skiatest::Reporter* r, bool useBBH) {
     }
 
     GrReplacements replacements;
-    GrReplacements::ReplacementInfo* ri = replacements.newReplacement(pic->uniqueID(), 
+    GrReplacements::ReplacementInfo* ri = replacements.newReplacement(pic->uniqueID(),
                                                                       0, SkMatrix::I());
     ri->fStop = 2;
     ri->fPos.set(0, 0);