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

Issue 650523 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocked on:
issue 647028



Sign in to add a comment

MD History: scrolling is slow

Project Member Reported by dbeam@chromium.org, Sep 27 2016

Issue description

Scrolling up and down the new Material Design history page is slow.

In an ideal world, each scroll event would take <16.7ms (60FPS) on most machines.

In the real world, I'd settle for it scrolling at 60FPS on my Z620 (which it isn't yet).

Part of this is that iron-list is doing too much work or doing work at the wrong time (which has been partially addressed and will continue to improve as part of  bug 647028 ), but the other part is that we need to cheapen any repetitive DOM access to layout-causing properties (i.e. scrollHeight, scrollTop, offsetHeight).
 

Comment 1 by dbeam@chromium.org, Sep 28 2016

Cc: -calamity@chromium.org tsergeant@chromium.org
Owner: calamity@chromium.org
whoops, forgot to CC Tim

so there's quite a few things involved here and style calculation / layout performance seems to vary greatly depending on history contents

Elliott seems to think text-overflow might be a little slow and hard to optimize:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutBlockFlowLine.cpp?sq=package:chromium&dr=CSs&rcl=1475003988&l=1983

So, long URLs + titles will probably slow down iron-list's touching of .offsetHeight to calculate how many items to render / fit in the frame.

Additionally, egarciad@ is doing a couple things to address this by:

a) providing APIs to tell iron-list the sizes of items
b) caching multiple touches to iron-scroll-target's scrollTop property in a single scroll event
Status: WontFix (was: Available)
I believe this is pretty obsolete.

Sign in to add a comment