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
diff --git a/src/core/SkRecordDraw.cpp b/src/core/SkRecordDraw.cpp
index 12579e9..5981245 100644
--- a/src/core/SkRecordDraw.cpp
+++ b/src/core/SkRecordDraw.cpp
@@ -164,13 +164,7 @@
// Finally feed all stored bounds into the BBH. They'll be returned in this order.
SkASSERT(bbh);
- bbh->reserve(record.count());
- for (unsigned i = 0; i < record.count(); i++) {
- if (!fBounds[i].isEmpty()) {
- bbh->insert(i, fBounds[i], true/*ok to defer*/);
- }
- }
- bbh->flushDeferredInserts();
+ bbh->insert(&fBounds, record.count());
}
template <typename T> void operator()(const T& op) {