GitLab

When using an unaccelerated canvas with a compositor using Gpu raster,
each canvas update is rasterized to a bitmap pushed into a paint
recording. This bitmap is uploaded and cached by cc's
GpuImageDecodeCache. Since the canvas is frequently updated, it is
common for the Gpu cache to use and keep the discardable texture memory
to capacity.

Avoid the above situation by actively deleting canvas snapshots in the
Gpu cache. PaintImages from a canvas instance use a stable
PaintImage::Id and update the PaintImage::ContentId when an updated
snapshot is created. This patch ensures that the Gpu cache keeps the
max 2 ContentId entries for the same PaintImage::Id (pending and active
tree), effectively ensuring we only have the last 2 canvas snapshots.

Note that BitmapImage, for encoded images in blink, also uses an updated
ContentId as more data is fetched for an image. This change will also
ensure that we evict previous partially decoded frames for the same
image.

For play:media:soundcloud test case on my linux machine, this reduced
cc's cache size from 236M to 30M.

R=enne@chromium.org, ericrk@chromium.org

Bug: 814219
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I888155ae5504ece6ab73981f320515478d87917d
Reviewed-on: https://chromium-review.googlesource.com/987194
Commit-Queue: Khushal <khushalsagar@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551078}