gifs definitely did not break in webview, so it must be something specific to your app. Can you upload an apk as well as source code for that apk to demonstrate the bug

Hi,

For security reasons I can't share my main application apk. But I have created a sample project which contains the code that I have used in my main application.

PFA the source and apk file for sample project.

Deleted: app-debug.apk 2.6 MB

app-debug.apk 2.6 MB Download

Deleted: GifSample.zip 15.1 MB

GifSample.zip 15.1 MB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

problem is mWebView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

removing that fixes this. While I can't think of any reason why software layer would break gifs, is there any reason you are putting the webview in a software layer in the first place? Webview software mode is in maintenance mode, and isn't getting tested thoroughly anymore

Looking at traces, it looks like gif animations are ticked on the compositor thread, which creates a pending tree and with a new frame uploaded to GPU. However that code path just breaks webview's resourceless (ie tile-less) software draws, since it doesn't use any tiles.

khushalsager/ericrk: can either of you confirm that?

The logic for using the current frame of the animation is hooked using cc's tile raster code, if resourceless Webview doesn't use that then it would break. I'll see how to fix it.

Fix uploaded: https://chromium-review.googlesource.com/c/chromium/src/+/1087321

@boliu, as per your suggestion I have removed the line  mWebView.setLayerType(View.LAYER_TYPE_SOFTWARE, null). It is working properly now. 

If we are not setting any layerType, will it impact on performance of the application. The gif file size of the we are using is of 1.5MB.

what kind of performance impact? because using webview in software mode definite hurts performance of the webview

I meant the performance of the webView in animating the gif file. 

LAYER_TYPE_SOFTWARE is a lot slower than no layer, so yes there is a performance impact to removing LAYER_TYPE_SOFTWARE, but the performance impact is positive

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

commit 418507c638dd9032b0e4bd08e6a3caf089f8f374
Author: Khushal <khushalsagar@chromium.org>
Date: Wed Jun 06 22:37:31 2018

cc/viz: Support animated images in Webview resource-less draw.

The image animation system selects the frame index for the animation
during tile raster. As a result updating the frame of the image is
missed for Webview resourceless draw mode which does not use these tiles
and later rasterizes the display list in SoftwareRenderer. Plumb through
the animation state on the PictureDrawQuad and use it to select the
frame index for image at raster.

R=boliu@chromium.org, danakj@chromium.org

Bug:  849565 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I20f48a664ae816da29e7d55012b7da4dec488ede
Reviewed-on: https://chromium-review.googlesource.com/1087321
Reviewed-by: Eric Karl <ericrk@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565066}
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/cc/paint/paint_image.h
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/cc/test/fake_paint_image_generator.cc
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/cc/test/fake_paint_image_generator.h
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/cc/test/layer_tree_test.cc
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/cc/test/layer_tree_test.h
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/cc/trees/layer_tree_host_unittest.cc
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/components/viz/common/quads/draw_quad_unittest.cc
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/components/viz/common/quads/picture_draw_quad.cc
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/components/viz/common/quads/picture_draw_quad.h
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/components/viz/service/display/renderer_pixeltest.cc
[modify] https://crrev.com/418507c638dd9032b0e4bd08e6a3caf089f8f374/components/viz/service/display/software_renderer.cc

boliu@, do you think this warrants a merge to 68? I'm guessing not.

I agree with not merging. It's been in stable for 2 release already. One more isn't going to matter that much.

Great. Should be fixed in M69 then.

 Issue 850845  has been merged into this issue.