Composited overflow scrollers do not need a composited graphics layer. |
||
Issue descriptionVersion: 53.0.2785.70 (Official Build) beta (64-bit) OS: All What steps will reproduce the problem? (1) On a high DPI device, visit http://output.jsbin.com/vodacu (or any page with an overflow scroller) (2) Record a frame viewer trace What is the expected output? Expect the scrolling contents layer to be promoted. What do you see instead? See that both the scrolling contents layer and the graphics layer of the overflow scroller have been promoted. We do not need to create a graphics layer for the overflow scroller to get composited scrolling; we could paint the border, background, box shadow, etc into the squashing layer. This would save us a layer on every composited overflow scroller of the size of that overflow scroller. Please use labels and text to provide additional information.
,
Sep 16 2016
Yes it's possible, but is it worth the complexity? that would mean that painting from the parent would have to recurse into the "self-composited" element that has composited scrolling and paint its border. Right now it's a painting invariant that you never recurse into a child PaintLayer which has a CompositedLayerMapping. Another reason is that SPv2 is coming soon, so we should only do very high-value work on the old system.
,
Sep 16 2016
I agree, if SPv2 will remove this extra layer then I think we can wait. This does require a fair bit of extra complexity.
,
Sep 16 2016
Ok. |
||
►
Sign in to add a comment |
||
Comment 1 by flackr@chromium.org
, Aug 31 2016