Remove restrictions for directly compositing images to save tile memory
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}
Showing






