New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 331352 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 331848
Owner: ----
Closed: Jan 2014
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Compat



Sign in to add a comment

Catastrophic flexbox layout perf while opening <select>

Reported by netmosf...@gmail.com, Jan 2 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Example URL:

Steps to reproduce the problem:
I'm not sure whether this is a flexbox problem or it's a peculiarity of select-one fields: probably there are two bugs listed there.

Open the attached demo

Open the <select> which shows "!!!CLICK HERE!!!"; it doesn't contain many options, but rendering is slow because opening the select's popup causes a full document re-render.

What is the expected behavior?

What went wrong?
Now, the full document re-render happens with a "display:block" layout as well, but with flexbox the problem is highly accentuated (up to 2s rendering), whereas with display:block the rendering time is really low.

http://i.imgur.com/yy89g22.png

I think the select-one dropdown display should never cause a full document redraw. But I believe you should firstly investigate on the reason why this is so slow with flexbox instead to be as fast as display:block.

To test the display:block render, just add *{display:block !important;}

(this may be related to https://code.google.com/p/chromium/issues/detail?id=306716 but not sure)

Happens on Windows 7, also on Chrome Canary (34), I didn't test on other platforms.

hth

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? N/A 

Chrome version: 31.0.1650.63  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 11.9 r900
 
bug.zip
6.0 KB Download
Cc: ojan@chromium.org jchaffraix@chromium.org
Labels: Cr-Blink-Performance
Summary: Catastrophic flexbox layout perf while opening <select> (was: optimize select-one fields for flexbox)
Hosted demo: https://dl.dropboxusercontent.com/u/39519/temp/crbug-331352/test.htm

I believe this is two bugs:

1. Opening the <select> triggers a recalc style and Layout.
2. The layout perf is terrible. Nearly 2s on my MBA.
Screen Shot 2014-01-02 at 3.09.32 PM.png
91.2 KB View Download
that's even worse than that, modifying the dom subtree sometimes hangs the rendering for 30-60" when chrome doesn't crash :(

workarounds are super welcome!

Comment 3 by ojan@chromium.org, Jan 3 2014

Here's a standalone test case that does the layout in a loop 100 times. 

Looking at a profile, 1/3rd of the time is in n^2 layout due to align-items: stretch. 
scratch.html
31.0 KB View Download

Comment 4 by ojan@chromium.org, Jan 3 2014

Cc: tabatkins@chromium.org cbiesin...@chromium.org esprehn@chromium.org abarth@chromium.org tony@chromium.org
Changing from:
* { align-items:stretch;align-self:stretch; }

to:
* { align-items:flex-start;align-self:flex-start; }

Causes the layout time to go from 345ms to 8ms on my machine (although 8ms is still to slow for such a simple page!). Removing the align-items value entirely (so only some things get stretched) makes the layout time ~100ms.

It was really a mistake to make stretch the default value. :( I wish we had pushed back harder on that decision. I think we're stuck with it now though. We should take a close look at grid layout to make sure we push back on any n^2 layouts.

The only fix I can think of for this is to avoid the n^2 layout in some cases by detecting if the contents of the flex-item needs a relayout after stretching (e.g. does it have a background color, percentage height descendants, overflow, etc). That's complicated error-prone logic though.

Comment 5 by ojan@chromium.org, Jan 3 2014

https://codereview.chromium.org/99663004/ adds the beginnings of a method for determining whether changing the height of an element requires a new layout.
what is weird is that if i do

align-self:flex-start;width:100%; (in a flex-direction:column; context)

which is basically the same as stretch, it will be much, much faster

Comment 7 by ojan@chromium.org, Jan 4 2014

Actually the n^2 only applies to flex-direction:row. For column flexboxes, we already have code that essentially does align-self:flex-start;width:100%; under the hood. 
ok, i guessed it was the same :P hope you will find a solution! thank you

Comment 9 by ojan@chromium.org, Jan 8 2014

Cc: le...@chromium.org pdr@chromium.org
Levi's patch might fix some of this. Turns out there's at least one genuine bug hiding here. https://codereview.chromium.org/129633004/
Mergedinto: 331848
Status: Duplicate

Sign in to add a comment