Unable to reproduce the issue on Windows 7, Mac 10.12.4 & Ubuntu 14.04 using chrome reported version -60.0.3095.5 & latest Canary-60.0.3096.0 as per the steps & html file provided in comment#0.

Observed "div#widget-w11" has size ( width 779px x height 1118px).

Please find the attached screen cast for reference & let us know if we miss any steps to reproduce the issue.
Thanks in advance..!!

Deleted: 721222.mp4 1.3 MB

	721222.mp4 1.3 MB View Download

Hi! thanks for trying to repro! The strange thing is that the computed styles looks correct, but if you enable the `layers` feature in chrome, you should be able to see the layers similar to the screenshot I have attached. The extra large layer is causing some serious flickering problem in my end but its much harder to reproduce since i think it's caused by interactjs filing off some mouse event that's not support to happen

Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested this issue on Mac 10.12.4 with chrome #58.0.3029.110 with provided url in comment #0

Observed in devtools -> Elements tab, it showing width x height as 779 x 1118
whereas in devtools -> Layers tab, it showing W x H as 883 x 1103 which is different from comment #0 W x H as (10778 x 1118)

Attaching the screen-cast of this behavior.

sixin210@ Could you please look into it and let us know any steps i have missed while reproducing the scenario.

Thank You...

Deleted: Issue 721222.mp4 1.4 MB

	Issue 721222.mp4 1.4 MB View Download

Reproduces on a mac with retina display, because we composite the children and then squash things together. I thought we had a bug for this to avoid very empty squashing layers but I can't find it.

Team: How easy is it to avoid this?

Yea, I too remember there is a heuristic in CompositedLayerAssigner to avoid sparse squash layers. Also this is an issue we need to think about for SPv2 too.

That said, I always wondered how bad sparse layers are? AFAIK we do detect solid color tiles, and skip drawing for empty tiles. We still have to compute coverage and iterate over empty tiles, but 10778x1118 (~200 tiles to iterate) doesn't sound too terrible to me.

I think the real problem from sparse layers is that a single pixel can cause a tile of 256x256 to be generated and drawn. I feel that it would be advantageous to calculate cull rect per tile to allow partial tiles.

+cc danakj@ for opinions from cc expert.

Hi Kkaluri, 

I have 10.11.6 (15G1510), and here's a GIF of the repro - i wonder if your "#document" could be open? It's one of its children that's huge

Deleted: 721222-repro.gif 5.5 MB

	721222-repro.gif 5.5 MB View Download

it's a MacBook Pro (Retina, 15-inch, Mid 2014), if this is helpful

Our solid color detection exists but is not the most amazing, it early outs if there is more than 1 paintop for example.

Also iterating 200 tiles is not the same as iterating 200 integers in an array. It means computing geometry with mapping transforms, to prioritize them, and building them into queue data structures and such. The cost is probably more than you'd expect.

Im not 100% on the impact of our solid color detection wrt sparse layers, but all the edges around the sparseness will be full tiles, so you could expect a lot more memory used I think.

Maybe you can disable sparse layer squashing on some bad cases and run telemetry and compare what happens if you're curious?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot