GitLab

With cc-based directly composited images, we previously made a decision
to not directly composite images if raster scale and aspect ratio
resulted in filling in tiles that end up truncated when scaled back up
in the display compositor, based on the shared quad state transform.

However, because we don't apply directly composited images in cases
where we used to, we can end up using more tile memory. The example
page from bug 1111621 has over a hundred 1572 x 861 size image layers,
but the image is only 16x16. If we don't directly composite, we run into
the upper limits of allowed tile memory, and tiles start disappearing
(are dropped) on re-draw.

Unfortunately, as raster scale can only be expressed as a single
scaler value, there no way to have tile size match the intrinsic image
size when the aspect ratio of the layer and image are different (the
previous approach was able to do this by encoding x and y scales in the
layer transform - however, our detection of directly composited images
happens later in the pipeline at a time where we cannot alter the
structure of the transform property tree).

This change removes the restriction (and the associated DCHECK
validating it) when the raster scale is less than 0.1, in favor of
applying directly composited images to save memory, over the minor
changes in rendering that may result. The difference in rendering is
that the last row/column of scaled pixels will only be partially filled,
and those pixels will be stretched and clipped at the layer bounds.

Bug: 1111621

Change-Id: I15b83a9f33df72f40ece087ade3e82a513aa596e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2355831Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: Daniel Libby <dlibby@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#799861}