Refactoring how SkDeferredCanvas manages mutable bitmaps
This CL makes the SkGPipe flavor of SkDeferredCanvas properly
decide whether to flush or record mutable bitmaps. The flushing
is now managed by conditionally switching the canvas to non-deferred
mode, which avoids an unnecessary transient copy of the bitmap.
BUG=http://code.google.com/p/chromium/issues/detail?id=137884
TEST=DeferredCanvas unit test, sub test TestDeferredCanvasMemoryLimit
Review URL: https://codereview.appspot.com/6421060
git-svn-id: http://skia.googlecode.com/svn/trunk@4756 2bbb7eff-a529-9590-31e7-b0007b416f81
diff --git a/tests/DeferredCanvasTest.cpp b/tests/DeferredCanvasTest.cpp
index 449f5e9..0fee180 100644
--- a/tests/DeferredCanvasTest.cpp
+++ b/tests/DeferredCanvasTest.cpp
@@ -205,16 +205,14 @@
sourceImage.setConfig(SkBitmap::kARGB_8888_Config, 100, 100);
sourceImage.allocPixels();
- for (int i = 0; i < 6; i++) {
+ for (int i = 0; i < 5; i++) {
sourceImage.notifyPixelsChanged(); // to force re-serialization
canvas.drawBitmap(sourceImage, 0, 0, NULL);
}
- // FIXME: Test temporarily disabled because the SkPicture path is not
- // fixed and the SkGPipe path does not yet serialize images, but it
- // will soon.
-#if 0
- REPORTER_ASSERT(reporter, mockDevice.fDrawBitmapCallCount == 4);
+ // SkPicture path is not fixed
+#if SK_DEFERRED_CANVAS_USES_GPIPE
+ REPORTER_ASSERT(reporter, mockDevice.fDrawBitmapCallCount == 3);
#endif
}