Initial work to get ETC1 data up to the GPU

src/gpu/GrGpu.h

Index: src/gpu/GrGpu.h
diff --git a/src/gpu/GrGpu.h b/src/gpu/GrGpu.h
index 11f87e0458d9b0b8b0aa3cd386ee7363d4a6028c..2739dad4651b60ff3a7a5c91df9dd1bce6f802d5 100644
--- a/src/gpu/GrGpu.h
+++ b/src/gpu/GrGpu.h
@@ -87,6 +87,26 @@ public:
                              const void* srcData, size_t rowBytes);
 
     /**

[robertphillips, 2014/05/30 15:00:22]

Can we test these cases (on a Xoom say) ?

+     * Creates a compressed texture object. If desc width or height is not a power of
+     * two but underlying API requires a power of two texture then this function will
+     * return NULL. If the pixel configuration passed in desc is not a valid format
+     * supported by the device, then this function will return NULL.
+     *
+     * The kRenderTarget_TextureFlag should not be specified
+     *
+     * @param desc        describes the texture to be created. The width and height of
+     *                    the texture should be multiples of the block size for the
+     *                    requested compressed format. The origin of the texture is
+     *                    also expected to be in the top left.
+     * @param srcData     texel data to load texture. This is expected to be the
+     *                    proper size based on the width and height of the texture along
+     *                    with the associated block size specified in GrTextureFormatDesc
+     *
+     * @return    The texture object if successful, otherwise NULL.
+     */
+    GrTexture* createCompressedTexture(const GrTextureDesc& desc, const void* srcData);

[bsalomon, 2014/05/30 15:16:58]

I'm wondering if this makes sense as a public GrGpu function. I can see wanting
to split in the implementation (either as onCreateTexture and
onCreateCompressedTexture or in the GrGpuGL code), but isn't the distinction
between creating a compressed or uncompressed texture now already captured in
the desc's config? Why make the caller worry about this detail?

[krajcevski, 2014/05/30 16:21:50]

I agree to an extent... it's always better to be implicit rather than explicit.
That being said, the distinction between compressed versus uncompressed textures
probably doesn't need to be at this height of the API. I've changed the
description to reflect the new behavior of createTexture by moving
createComrpessedTexture logic into it.

+
+    /**
      * Implements GrContext::wrapBackendTexture
      */
     GrTexture* wrapBackendTexture(const GrBackendTextureDesc&);
@@ -414,6 +434,8 @@ private:
     virtual GrTexture* onCreateTexture(const GrTextureDesc& desc,
                                        const void* srcData,
                                        size_t rowBytes) = 0;
+    virtual GrTexture* onCreateCompressedTexture(const GrTextureDesc& desc,
+                                                 const void* srcData) = 0;
     virtual GrTexture* onWrapBackendTexture(const GrBackendTextureDesc&) = 0;
     virtual GrRenderTarget* onWrapBackendRenderTarget(const GrBackendRenderTargetDesc&) = 0;
     virtual GrVertexBuffer* onCreateVertexBuffer(size_t size, bool dynamic) = 0;