New issue
Advanced search Search tips

Issue 619629 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocking:
issue 79180



Sign in to add a comment

[css-grid] Very poor layout performance with nested grids

Reported by a...@scirra.com, Jun 13 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2766.0 Safari/537.36

Example URL:
https://dl.dropboxusercontent.com/u/15217362/bugs/nested-grid-perf/index.html

Steps to reproduce the problem:
1. Visit the given URL.
2. Move the mouse around. This causes a randomly generated grid to resize and therefore cause layout in the browser.

What is the expected behavior?
Fast layout with a reasonably small number of elements.

What went wrong?
The layout performance is extremely slow, even on a high-end dev machine. The page tries to measure this itself (as interval between rAF calls) and reports figures around 500ms for me. Dev tools timeline measures each layout around 250ms. This is extremely high for a 30-row grid.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 53.0.2766.0  Channel: canary
OS Version: 10.0
Flash Version: Shockwave Flash 22.0 r0

The demo simply wraps the 30-row grid with 3 other wrapper elements with display: grid. This nesting appears to be the cause of the poor performance. Compare to the equivalent without the 3 wrapper elements: https://dl.dropboxusercontent.com/u/15217362/bugs/nested-grid-perf/no-nesting.html - this version is perfectly fast for me, ~20ms max jank measured and looks smooth. Therefore I suspect some kind of algorithmic inefficiency to do with layout on grids inside grids.

Firefox Nightly also is perfectly fast.

IIRC this is a regression and used to be fast, but I can't remember when it changed. Took a while to find a repro.
 
Components: -Blink Blink>Layout>Grid

Comment 2 by r...@igalia.com, Jun 14 2016

Blocking: 79180
Cc: svil...@igalia.com jfernan...@igalia.com r...@igalia.com
Labels: -OS-Windows OS-All
Status: Available (was: Unconfirmed)
Summary: [css-grid] Very poor layout performance with nested grids (was: [CSS grid] Very poor layout performance with nested grids)

Comment 3 by svil...@igalia.com, Sep 14 2016

Status: Assigned (was: Available)
I'm working on this. The culprit is the extra pass we added for rows resolution which is exponentially increasing the complexity of the layout. The more nesting levels the worst (on a geometrical progression).
Project Member

Comment 4 by bugdroid1@chromium.org, Sep 15 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7eeda9249ff7a744d713417830e4b71319879b87

commit 7eeda9249ff7a744d713417830e4b71319879b87
Author: svillar <svillar@igalia.com>
Date: Thu Sep 15 17:15:11 2016

[css-grid] Remove the 2x computation of row sizes w/ indefinite heights

On crrev.com/358816, among other things, we added a second pass of the track
sizing algorithm for rows in order to properly compute row sizes when the
height was indefinite. We did that in order to have a symmetrical
implementation for columns and rows, but unfortunatelly that was not
correct.

Apart from issuing incorrect results in some cases it created a huge
performance issue in the case of nested grids because we were exponentially
increasing the amount of executions of the track sizing algorithm. The attached
performance test shows a 350% improvement with the patch.

BUG= 619629 

Review-Url: https://codereview.chromium.org/2339983002
Cr-Commit-Position: refs/heads/master@{#418892}

[modify] https://crrev.com/7eeda9249ff7a744d713417830e4b71319879b87/third_party/WebKit/LayoutTests/fast/css-grid-layout/maximize-tracks-definite-indefinite-height.html
[add] https://crrev.com/7eeda9249ff7a744d713417830e4b71319879b87/third_party/WebKit/PerformanceTests/Layout/nested-grid.html
[modify] https://crrev.com/7eeda9249ff7a744d713417830e4b71319879b87/third_party/WebKit/Source/core/layout/LayoutGrid.cpp

Comment 5 by svil...@igalia.com, Sep 15 2016

Status: Fixed (was: Assigned)
Closing, please verify

Comment 6 by a...@scirra.com, Sep 19 2016

Yes, seems better now, thanks.
Can you check it with this example?
https://www.dropbox.com/s/hnlzaje8s963283/test.html?dl=0

When resize window it takes two second for layout. But edge is near realtime.
test.html
1.1 KB View Download

Comment 8 by r...@igalia.com, May 8 2018

Yes that case is slow, but please report a new bug as the issues in the initial example were solved long time ago.

BTW, it'd be nice to understand the use case and why you need so many nested grids (please comment about that on the new bug).
That will help us to prioritize the task.

JFYI, note that Firefox doesn't manage to open the example.

Sign in to add a comment