Extend SkImageGenerator to support natively generated GrTextures

include/core/SkImageGenerator.h

Index: include/core/SkImageGenerator.h
diff --git a/include/core/SkImageGenerator.h b/include/core/SkImageGenerator.h
index 83f36e09a7603caa55acc10e969e2ef412bdaa88..d5885babd7590941fd0a46c24d39c4d3738b7fab 100644
--- a/include/core/SkImageGenerator.h
+++ b/include/core/SkImageGenerator.h
@@ -11,8 +11,10 @@
 #include "SkColor.h"
 #include "SkImageInfo.h"
 
+class GrContext;
 class SkBitmap;
 class SkData;
+class GrTexture;
 class SkImageGenerator;
 class SkMatrix;
 class SkPaint;
@@ -56,6 +58,8 @@ public:
      */
     virtual ~SkImageGenerator() { }
 
+    uint32_t uniqueID() const { return fUniqueID; }

[scroggo, 2015/08/13 19:59:12]

If an SkImage or SkBitmap uses this generator, should it share this ID?

[reed1, 2015/08/13 20:57:08]

It will -- that is handled in my following CL

+
     /**
      *  Return a ref to the encoded (i.e. compressed) representation,
      *  of this data.
@@ -123,6 +127,30 @@ public:
                        SkYUVColorSpace* colorSpace);
 
     /**
+     *  If the generator can natively/efficiently return its pixels as a GPU image (backed by a
+     *  texture) this will return that image. If not, this will return NULL.
+     *
+     *  Regarding the GrContext parameter:
+     *
+     *  The caller may pass NULL for the context. In that case the generator may assume that its
+     *  internal context is current. If it has no internal context, then it should just return
+     *  null.
+     *
+     *  If the caller passes a non-null context, then the generator should only succeed if:
+     *  - it has no intrinsic context, and will use the caller's
+     *  - its internal context is the same
+     *  - it can somehow convert its texture into one that is valid for the provided context.
+     *
+     *  Regarding the SkImageUsageType parameter:
+     *
+     *  If the context (the provided one or the generator's intrinsic one) determines that to
+     *  support the specified usage, it must return a different sized texture (from the generator's
+     *  native size) it may, so the caller must inspect the texture's width/height

[scroggo, 2015/08/13 19:59:12]

I lost the thread of this sentence. Maybe it would be clearer to say:

If the context (...) must return a different sized texture (...) to support the
specified usage, it may.

I do not understand how the remainder of the sentence is related. It's also not
clear to me how it relates to the SkImageUsageType (except that kUntiled has
some special meaning relative to the others).

[reed1, 2015/08/13 20:57:08]

Done.

+     *  (unless kUntiled_SkImageUsedType was specified).
+     */
+    GrTexture* generateTexture(GrContext*, SkImageUsageType);
+
+    /**
      *  If the default image decoder system can interpret the specified (encoded) data, then
      *  this returns a new ImageGenerator for it. Otherwise this returns NULL. Either way
      *  the caller is still responsible for managing their ownership of the data.
@@ -138,7 +166,7 @@ public:
                                             const SkPaint*);
 
 protected:
-    SkImageGenerator(const SkImageInfo& info) : fInfo(info) {}
+    SkImageGenerator(const SkImageInfo& info);
 
     virtual SkData* onRefEncodedData();
 
@@ -148,8 +176,11 @@ protected:
     virtual bool onGetYUV8Planes(SkISize sizes[3], void* planes[3], size_t rowBytes[3],
                                  SkYUVColorSpace* colorSpace);
 
+    virtual GrTexture* onGenerateTexture(GrContext*, SkImageUsageType) { return nullptr; }
+
 private:
     const SkImageInfo fInfo;
+    const uint32_t fUniqueID;
 
     // This is our default impl, which may be different on different platforms.
     // It is called from NewFromEncoded() after it has checked for any runtime factory.