Add SkSpecialImage::makeTextureImage entry point & update filterInput

src/core/SkImageFilter.cpp

Index: src/core/SkImageFilter.cpp
diff --git a/src/core/SkImageFilter.cpp b/src/core/SkImageFilter.cpp
index 374a561030254561941ecf21e67d4a65cdfffe80..f7662c6e75fe5353bdafbcc1466ac93cebab0803 100644
--- a/src/core/SkImageFilter.cpp
+++ b/src/core/SkImageFilter.cpp
@@ -593,7 +593,16 @@ SkSpecialImage* SkImageFilter::filterInput(int index,
         return SkRef(src);
     }
 
-    return input->filterImage(src, this->mapContext(ctx), offset);
+    SkAutoTUnref<SkSpecialImage> result(input->filterImage(src, this->mapContext(ctx), offset));
+
+    if (src->peekTexture() && !result->peekTexture()) {

[Stephen White, 2016/03/17 17:10:08]

This is also done in filterInputGPU[Deprecated](). Is that path going away in
the new world?

Also, shouldn't this all be wrapped in #if SK_SUPPORT_GPU?

[robertphillips, 2016/03/17 21:01:47]

Right - filterInputGPU[Deprecated] should go away. Hopefully, this instance will
also go away and just be replaced with an assert.
Done.

+        // Keep the result on the GPU - this is still required for some
+        // image filters that don't support GPU in all cases

[Stephen White, 2016/03/17 17:10:08]

The only one I can think of off the top of my head is SkImageSource. Are there
others?

[robertphillips, 2016/03/17 21:01:47]

I believe the SkXfermodeImageFilter balks at cropRects. Some other
asFragmentProcessor calls can also fail.

[Stephen White, 2016/03/17 21:30:17]

I think you're misunderstanding what canFilterImageGPU() means.

SkXfermodeImageFilter falls back to the generic (two-pass) drawing if there's a
crop rect. It doesn't mean it won't produce a texture-backed result, or that it
won't process on the GPU, it just means it'll use generic Skia calls to do so.
The only ImageFilter I could find that could fail in asFragmentProcessor() is
SkAlphaThresholdFilter, which can fail to allocate a mask texture. We should
probably not be dropping back to software in that case, but just aborting
processing altogether.

What I'm really getting at is, if there are filters which are not processing on
the GPU (given a texture-backed input), I'd like to know. For now, doing the
upload in filterInput() is fine. But if it's only SkImageSource that needs it,
perhaps we could move the upload code there, and just assert that all results
are texture-backed if src is texture-backed. That could be in another patch, of
course.

+        GrContext* context = src->peekTexture()->getContext();
+        result.reset(result->makeTextureImage(src->internal_getProxy(), context));
+    }
+
+    return result.release();
 }
 
 #if SK_SUPPORT_GPU