From 4477c3c0e6eb064772aefe8737425cd1c2ce557f Mon Sep 17 00:00:00 2001 From: mtklein Date: Mon, 27 Oct 2014 10:27:10 -0700 Subject: 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 --- tests/PictureTest.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'tests/PictureTest.cpp') diff --git a/tests/PictureTest.cpp b/tests/PictureTest.cpp index 7546a5d5be..fa4dc10142 100644 --- a/tests/PictureTest.cpp +++ b/tests/PictureTest.cpp @@ -1869,7 +1869,7 @@ struct CountingBBH : public SkBBoxHierarchy { this->searchCalls++; } - virtual void insert(unsigned opIndex, const SkRect& bounds, bool defer) SK_OVERRIDE {} + virtual void insert(SkAutoTMalloc*, int) SK_OVERRIDE {} }; class SpoonFedBBHFactory : public SkBBHFactory { -- cgit v1.2.3