background-image should benefit from PictureImageLayer optimizations |
|||
Issue descriptionThis is a spin-off from https://bugs.chromium.org/p/chromium/issues/detail?id=596382 The example given there is: http://codepen.io/GreenSock/pen/rexpMG?editors=1000 That example in Chrome 49 shows img tag having much better visual results, but also better performance implications than a background-image tag. Fundamentally the dev is trying to do the same thing in both cases: show an image. But we take radically different paths to show it. Background-image is very commonly used for image atlasing, and an img tag won't work for that use case. We should apply the optimizations in the img case to the background-image case as well, when it's possible. This *would* have the side effect of fixing zoom animations with background-image by avoiding re-raster in skia. We should consider merging either this or 596382 back to M50 if possible cuz things look bad atm.
,
Apr 1 2016
Update: Discussed with Vlad and Enne, and decided to merge the behavior of PictureImageLayerImpl into PictureLayerImpl behind a toggle flag, that Blink can set per-layer. At first the toggle would be set by the existing triggers in CompositedLayerMapping, but then I'd add it for background image with no box decoration. Here are some more tidbits of the differences between PictureImageLayer* and PictureLayer* at present: 1. PictureImageLayerImpl doesn't re-raster on scale change 2. PictureImageLayerImpl rasters at the scale of the image, not the scale of the layer. The tiles rastered here are scaled down to fit the size of the layer. 3. PictureImageLayer paints with the lowest quality filter (none) This means that PictureImageLayer* results in a lower-quality rastered output due to #2 and #3, but can scale up to the intrinsic size of the picture without extra blurriness due to scaling beyond the raster buffer size. Here is an example comparing a PictureImageLayer to a PictureLayer of the same image: <!doctype HTML> <img style="position: relative; will-change: transform; width: 26%; " src="http://cdn.playbuzz.com/cdn/0079c830-3406-4c05-a5c1-bc43e8f01479/7dd84d70-768b-492b-88f7-a6c70f2db2e9.jpg"></img> <img style="border: 1px solid black; position: relative; will-change: transform; width: 26%; " src="http://cdn.playbuzz.com/cdn/0079c830-3406-4c05-a5c1-bc43e8f01479/7dd84d70-768b-492b-88f7-a6c70f2db2e9.jpg"></img> We decided that properties 1 and 2 are both important. A higher filter quality in 3 seems not useful because 2 would negate it anyway, due to the need to scale the raster tiles.
,
Apr 4 2016
Some more information: * PictureImageLayer was introduced in this CL: https://chromiumcodereview.appspot.com/11516005 but it was just re-implementing equivalent functionality for impl-side painting that already existed in the prior implementation (tiled image layers?) * This CL (https://chromiumcodereview.appspot.com/12326022) added an optimization to use transforms to animate the sizes of directly composited images, which avoids rastering them in that use case. Because of the latter, it is harder/not necessarily desirable to collapse code into PictureLayer.
,
Apr 5 2016
I don't think we should do this. Reasons why: 1. There are a ton of options and complexity already for how to paint background images (see the BackgroundImageGeometry class). 2. Even if we handled some of #1, we'd only be able to implement this for very special cases of no decoration, padding, repeat, etc. 3. And the code for #2 would inevitably be fragile and add complexity. Instead, I think we should provide a way for developers to express the desire to raster at a given scale. For the use case provided in comment 0 of this bug, the developer could raster at the intrinsic scale of the image, and then animate. See issue 600867 to follow this. |
|||
►
Sign in to add a comment |
|||
Comment 1 by chrishtr@chromium.org
, Apr 1 2016