Creating functions for uploading a mipmapped texture.

src/gpu/SkGr.cpp

Index: src/gpu/SkGr.cpp
diff --git a/src/gpu/SkGr.cpp b/src/gpu/SkGr.cpp
index bb041312450ae278c8ede6bf70dfedc6d02be3ba..7ae0671ccb9178bc51a8f4262abcc16e63c6a476 100644
--- a/src/gpu/SkGr.cpp
+++ b/src/gpu/SkGr.cpp
@@ -646,6 +646,41 @@ GrTexture* GrRefCachedBitmapTexture(GrContext* ctx,
 
     return NULL;
 }
+
+GrTexture* GrMipMapTexture(GrContext& ctx,
+                           const SkBitmap& bitmap,
+                           SkDiscardableFactoryProc fact) {
+    GrTexture* result = bitmap.getTexture();
+    // TODO: What if the bitmap already contains a non-mipmapped texture?

[bsalomon, 2015/08/26 18:30:11]

Maybe just preserve the existing glGenMipmaps()? texture-backed SkBitmaps are
going away anyway. Also we can have content generated on the GPU that needs to
be mipped, seems like calling the driver is right there.

[cblume, 2015/08/26 18:58:00]

Hrmmm the point of all this was to try to remove the call to glGenMipmaps(). I
suppose for this to matter the caller would need to be aware if the SkBitmap
they are passing is backed by a mipmapped texture or not so they can prevent the
call to glGenMipmaps(). I'm not sure if that is awkward for the caller to do.

How are texture-backed SkBitmaps going away? Maybe there is a better solution
using the new system.

GPU-generated content that needs to be mipped will be an interesting problem.
After a bit more research, it sounds like mipmaps may currently be generated by
rendering to the mipmap level. I would imagine it would be difficult to beat
that as far as speed but it may still cause jank on the GPU thread? Reading the
texture back out to the GPU would likely be worse.

[bsalomon, 2015/08/27 13:22:49]

The GrTexture tracks whether it's MIPs are "dirty" (rendered to) and only regens
if they are. SkBitmaps that are already explicitly texture backed (meaning they
actually own a texture rather than simply are associated with one in the cache)
represent content that was generated on the GPU. So I think glGenMipMipmaps is
probably a better solution than readpixels/cpu-gen/upload.

SkBitmaps backed by GrTextures are problematic because the interfaces on
SkBitmap was really designed around CPU-accessible pixels. Also, they make no
distinctions between sources and destinations. The replacement abstractions are
SkSurface and SkImage. SkImages are sources for draws and I think all the same
reasoning applies there (generate on CPU for sw-backed SkImages, glGenMipMaps
for inherently texture backed SkImages).

+    if (result) {
+        // TODO: Add stretching. After reading get_stretch(), it appears small
+        // textures can have issues.
+        return SkRef(result);
+    }
+
+    GrSurfaceDesc desc;
+    generate_bitmap_texture_desc(bitmap, &desc);
+
+    auto mipmap = SkMipMap::Build(bitmap, fact);
+    if (mipmap == NULL) {
+        // could not create the mipmap
+        return NULL;
+    } else {
+        auto mipLevelCount = mipmap->getLevelsCount();
+        SkTArray<SkMipMapLevel> texels(mipLevelCount);
+        for (int i = 0; i < mipLevelCount; i++) {
+            SkMipMap::Level level;
+            mipmap->getLevel(i, &level);
+
+            SkMipMapLevel currentMipLevel(level.fPixels, level.fRowBytes);
+
+            texels.push_back(currentMipLevel);
+        }
+        return ctx.textureProvider()->createTexture(desc, true, texels);
+        // TODO: BitmapInvalidator support
+    }
+}
+
 ///////////////////////////////////////////////////////////////////////////////
 
 // alphatype is ignore for now, but if GrPixelConfig is expanded to encompass