Oh wow. That definitely shouldn't be happening.
When we get the data size only, it sets the fillMode variable specifically for that reason.

I'm guessing it is somewhere within this if/else:
https://cs.chromium.org/chromium/src/third_party/skia/src/image/SkImage_Gpu.cpp?q=getDeferredTextureImageData&sq=package:chromium&dr=CSs&l=480

I'll investigate.

I think it's this call https://cs.chromium.org/chromium/src/third_party/skia/src/image/SkImage_Gpu.cpp?q=getDeferredTextureImageData&sq=package:chromium&dr=CSs&l=491

According to the comment we're really just checking if the data exists.

I think it'd be safe to replace the check for this->refEncoded() with as_IB(this)->peekCacherator()

Any progress on this?

Sorry for the slow response. This got pushed to the back burner.
The CR is https://codereview.chromium.org/2337803002/

The current hang-up is we have it designed to ask whether or not it would be cheap to get a texture from this SkImage. In the case of encoded images it would not be cheap.

However, pulling a texture from a different GL context is failing the tests. The design thinks it would indeed be cheap to get a texture -- it already is a texture. But it doesn't realize it is a texture on another context.


As a side not, it is failing on something independent of being cheap or not as well. Pixels do not match between the two context's textures.

If you see fit, you can add it under the umbrela of: https://bugs.chromium.org/p/chromium/issues/detail?id=709707

There seem to be a variety of other thoughts here not specifically related to the speed of calling getDeferredTextureImageData (esp. when just the size is needed).

If that (above) is still the gist of this bug, I think we can just remove the call to refEncoded() entirely, and add an explicit check to return 0 if the image is already texture-backed.

I will write up a CL to that effect. 

We want getDeferredTextureImageData to fail on picture-backed images and possibly on non-encoded raster images as well.

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/7f1d020bbfde245281fac88ff09b55366155be16

commit 7f1d020bbfde245281fac88ff09b55366155be16
Author: Mike Reed <reed@google.com>
Date: Tue May 09 03:52:03 2017

remove (possibly slow) call to refEncoded in getDeferredTextureImageData


- explicitly reject already-texture-backed and picture-backed

Needed to add a virtual to image_base and generator to distinguish
generators that can (or cannot) natively "generate" on the gpu (e.g. pictures)
Bug:  646089 
Change-Id: I3aea22f89b31009ecbb3bd50d88512e6532f0a0f

Change-Id: I3aea22f89b31009ecbb3bd50d88512e6532f0a0f
Reviewed-on: https://skia-review.googlesource.com/15765
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>

[modify] https://crrev.com/7f1d020bbfde245281fac88ff09b55366155be16/src/image/SkImage_Base.h
[modify] https://crrev.com/7f1d020bbfde245281fac88ff09b55366155be16/src/core/SkPictureImageGenerator.h
[modify] https://crrev.com/7f1d020bbfde245281fac88ff09b55366155be16/include/core/SkImageGenerator.h
[modify] https://crrev.com/7f1d020bbfde245281fac88ff09b55366155be16/src/image/SkImage_Lazy.cpp
[modify] https://crrev.com/7f1d020bbfde245281fac88ff09b55366155be16/src/image/SkImage_Gpu.cpp

vmpstr@ Does this appear to be fixed now?

I imagine bsalomon@'s concern was addressed since he gave a +1 on the code review.

Yes, my concern was addressed. 

This looks fixed now. Thanks.