Creating functions for uploading a mipmapped texture.

include/gpu/GrTextureProvider.h

Index: include/gpu/GrTextureProvider.h
diff --git a/include/gpu/GrTextureProvider.h b/include/gpu/GrTextureProvider.h
index 28fda48c43e87dbf17d033e6fa37d0f62dc68a57..d96b2c516aa1db36ae38b2e9f064b1edede15f18 100644
--- a/include/gpu/GrTextureProvider.h
+++ b/include/gpu/GrTextureProvider.h
@@ -9,6 +9,7 @@
 #define GrTextureProvider_DEFINED
 
 #include "GrTexture.h"
+#include "SkMipMap.h"
 
 class SK_API GrTextureProvider {
 public:
@@ -29,6 +30,18 @@ public:
     GrTexture* createTexture(const GrSurfaceDesc& desc, bool budgeted, const void* srcData,
                              size_t rowBytes);
 
+    /**

[bsalomon, 2015/07/22 17:21:10]

What do you think about combining createTexture and createMipMappedTexture into
one function that takes a mip level iterator?

Something like

GrMipIterator {
    virtual int levelCount();
    virtual void* getLevel(size_t* rowBytes);
}

?

And then we could still have a createTexture() that takes a void*/size_t and
calls the "real" version with a single level. All the downstream calls wouldn't
need to impls, though.

[cblume, 2015/07/22 18:32:40]

I like that idea.

In general, I am in favor of having one function instead of two. Elsewhere in
this CL you can see some of the functions I refactored to take an SkTArray of
mip levels. And the places with only 1 mip level only populate 1 element of that
array. So I very much think that would be a good idea.

For that to work I beliebe we'll have all the piping take the mip iterator or
mip array and only the topmost layer would continue to take void*/size_t. Is
that what you were thinking?

[cblume, 2015/07/24 23:49:03]

Thinking a bit more about this...ideally mipmapped and non-mipmapped textures
textures behave the same and we can just have one function for each piece of the
pipeline.

However, there may be cases where it is not yet clear that we can treat them the
same.

For example, should the scratch texture have mipmaps? If so we'll need it to
have >= the number of mipmap levels we plan to allow as a max. That also means
extra memory usage (although, maybe not much?).

It may also mean changing the stretch code to also stretch the mipmaps but that
is do-able. In fact, I think we'll end up needing to do it. So that is okay.

What do you think?

+     * Creates a new mipmapped texture in the resource cache and returns it. The
+     * caller owns a ref on the returned texture which must be balanced by a
+     * call to unref.
+     *
+     * @param desc     Description of the texture properties.
+     * @param budgeted Does the texture count against the resource cache budget?
+     * @param srcData  The mipmap data used to populate the texture.
+     */
+    GrTexture* createMipmappedTexture(const GrSurfaceDesc& desc, bool budgeted,
+                                      const SkMipMap& srcData);
+
     /** Shortcut for creating a texture with no initial data to upload. */
     GrTexture* createTexture(const GrSurfaceDesc& desc, bool budgeted) {
         return this->createTexture(desc, budgeted, NULL, 0);