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

Issue 661476 link

Starred by 7 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Slow display list invalidation ('Update Layer Tree') when page has large number of absolutely positioned static elements

Reported by insensi...@gmail.com, Nov 2 2016

Issue description

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

Steps to reproduce the problem:
1. Visit https://jsfiddle.net/ssy1dqem/ 
2. Look at the animation performance
3. Reduce/Increase number in squaresCount variable
4. Look at the animation performance increase/decrease
5. Set 'useAbsolutePosition' to false
6. Look at the animation performance increase

What is the expected behavior?
Animation/display list invalidation for just one element should not decrease when page has large number of absolutely positioned static elements .

What went wrong?
Animation on the fiddle slows down proportionally to 'squaresCount' variable when using absolutely positioned elements. Animation is smooth in Firefox/Edge not depending on 'squaresCount' variable value or 'useAbsolutePosition' flag. Chrome DevTools Timeline shows that most time is spent on 'Layout/Update Layer Tree' rendering phases.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 54.0.2840.71  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

This might be event more critical on mobile Chrome when using absolutely positioned elements due to CPU/GPU resource limitations on mobile platforms.
 
Cc: sureshkumari@chromium.org
Labels: M-56 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on windows-7, Mac-10.11.6 and Linux Ubuntu-14.04 using 
chrome stable version 54.0.2840.87 and latest canary 56.0.2907.0 with below steps
1.opened Chrome
2.Navigated to the page https://jsfiddle.net/ssy1dqem/  
observed that the animation is slow which was not noticed in other browser(Firefox).  

This is non-regression issue observed from M-30 # 30.0.1550.0 to canary 56.0.2907.0. Hence marking it as Untriaged to get it addressed.

Thanks.

Comment 2 by rbyers@chromium.org, Nov 14 2016

Components: Blink>Compositing
Components: -Blink>Compositing Blink>Paint>Invalidation Blink>Layout
Status: Available (was: Untriaged)
Project Member

Comment 4 by sheriffbot@chromium.org, Nov 21 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
As reporter, I still think that this issue is important. In Firefox you can see smooth animation in provided JsFiddle snippet. Hope Chrome will be able to provide smooth animation too.
Status: Available (was: Untriaged)
Project Member

Comment 7 by sheriffbot@chromium.org, Nov 28

Status: Untriaged (was: Available)
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
Status: Available (was: Untriaged)

Sign in to add a comment