Seems like an Android OS issue as per the description. Marking the OS label appropriately.

I found out that if you put the phone to sleep and wake it up, the canvas contents appear.

I suspect this is an issue with how "display list canvas" interacts with deferred decoding.

@vmpstr: when deferred-decoded images are passed to the compositor, embedded in an SkPicture, what is the mechanism that triggers the required decodes?  In this case, the images are embedded indirectly in a nested SkPicture via SkPictureImageFilter.

What I think is happening that the first time the compositor rasterizes the SkPicture, there are some not yet decoded images that get bypassed. The second time the the content is rasterized (due to some form of invalidation), the images appear.  It's as if rasterization did not force images to be synchronously decoded.

The deferred images are processed by the compositor right now if they appear as a drawImage{,Rect} calls. If there is an image that appears as an SkPictureImageFilter, then we just pass that straight to Skia and rely on Skia to do the decode.

It should never be the case that we skip the image altogether and rasterize content without it. That is, if the image isn't decoded at the time of raster, both Skia and the compositor should be decoding it synchronously. Is it possible that the first time the image appears there is no associated invalidation with it?

That is, if we rasterize content, and the image is inserted without invalidation, then we won't rerasterize the content. Later, when you force an invalidation the image is rasterized.

Okay, so synchronous decodes are forced at raster time if necessary.  That's the bit I really needed to know.

Bad invalidations are definitely a possible cause, but I would expect the problem to be more widespread if that were the case. I will look deeper into that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6cfd221afcf593c701f2fce3ffbebdb4b2201968

commit 6cfd221afcf593c701f2fce3ffbebdb4b2201968
Author: junov <junov@chromium.org>
Date: Wed Jun 08 21:26:40 2016

Fix 2D canvas entiring invalid state when painted during hibernation

painting a canvas while the canvas is in a hibernation state was causing
the canvas to allocate a non-accelerated surface backing, which would
later cause GPU texture preparation to fail after exiting from hibernation.
This fix prevents "Canvas2DLayerBridge::newImageSnapshot()" from triggering
the creation of a surface whil the canvas is in a hibernating state.

BUG= 613513 

Review-Url: https://codereview.chromium.org/2051513002
Cr-Commit-Position: refs/heads/master@{#398681}

[modify] https://crrev.com/6cfd221afcf593c701f2fce3ffbebdb4b2201968/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
[modify] https://crrev.com/6cfd221afcf593c701f2fce3ffbebdb4b2201968/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp

 Issue 602246  has been merged into this issue.

 Issue 607243  has been merged into this issue.

 Issue 599177  has been merged into this issue.