Proposed SkCanvas API for preLoading textures to VRAM v2.0
This is an update to (Proposed SkCanvas API for preLoading textures to VRAM - https://codereview.chromium.org/192853002/). It takes into account in-person feedback on the initial proposal. The main feedback was to land this closer to where we will ultimately wind up with the reordered rendering capability (and don't have an SkCanvas entry point (yet)).
Committed: http://code.google.com/p/skia/source/detail?r=13810
R=reed@google.com, bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/197123003
git-svn-id: http://skia.googlecode.com/svn/trunk@13822 2bbb7eff-a529-9590-31e7-b0007b416f81
diff --git a/include/core/SkDevice.h b/include/core/SkDevice.h
index 2d9b0fc..7161bb1 100644
--- a/include/core/SkDevice.h
+++ b/include/core/SkDevice.h
@@ -423,6 +423,24 @@
*/
SkDeviceProperties fLeakyProperties;
+ /**
+ * PRIVATE / EXPERIMENTAL -- do not call
+ * Construct an acceleration object and attach it to 'picture'
+ */
+ virtual void EXPERIMENTAL_optimize(SkPicture* picture);
+
+ /**
+ * PRIVATE / EXPERIMENTAL -- do not call
+ * This entry point gives the backend an opportunity to take over the rendering
+ * of 'picture'. If optimization data is available (due to an earlier
+ * 'optimize' call) this entry point should make use of it and return true
+ * if all rendering has been done. If false is returned, SkCanvas will
+ * perform its own rendering pass. It is acceptable for the backend
+ * to perform some device-specific warm up tasks and then let SkCanvas
+ * perform the main rendering loop (by return false from here).
+ */
+ virtual bool EXPERIMENTAL_drawPicture(const SkPicture& picture);
+
private:
friend class SkCanvas;
friend struct DeviceCM; //for setMatrixClip