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

Issue 759496 link

Starred by 5 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression : Delay is seen in Files App while scrolling using Mouse wheel or by touch-pad

Project Member Reported by mmanchala@chromium.org, Aug 28 2017

Issue description

Chrome Version: 62.0.3197.0/9885.0.0 dev-channel Reks,Candy and Peppy
OS: Chrome

What steps will reproduce the problem?
(1)Sign into User -> Download images (above 30  such that scrollbar is seen in Files App)or Take Screenshots using  'Ctrl+F5(Overview Mode Button)'  
(2)Now go to Files App -> Try to scroll using Mouse wheel or  by touch-pad and observe delay (Please refer video)

Expected: No delay should be seen
Actual: Instead delay is seen  in Files App

This is Regression Issue seen from M-58

@fukino : Please confirm the Issue
 
Actual.webm
2.6 MB View Download
Expected.webm
2.2 MB View Download

Comment 1 by fukino@chromium.org, Aug 30 2017

Cc: yamaguchi@chromium.org

Comment 2 by fukino@chromium.org, Aug 30 2017

Confirmed.
It used to be rare to see that items inside viewport are not visible.
I'll look into it.
This issue started from https://codereview.chromium.org/2654873006.
Introducing overlay scrollbar somehow affects the scrolling item's visibility.
I'll investigate more details.

It's more complicated than I thought:

1) Before we started to use native overlay scrollbar (https://codereview.chromium.org/2554433002/), the issue did not happen.
2) Just after we started using native overlay scrollbar, the issue did not happen.
3) Just after we stopped using native overlay scrollbar by reverting the change (https://codereview.chromium.org/2654873006), the issue started to happen.

It seems I need to bisect changes between 1 and 3 by reverting the native overlay scrollbar in each step.
Status: Started (was: Assigned)
Cc: oka@chromium.org
Interestingly, this issue started from https://codereview.chromium.org/2594613002, though the CL does not look like a patch affecting scrolling items.

Checkout https://crrev.com/0667c0d63e43c625009d47031fbe9929cdac9864 and revert the change about native scroll bar (https://codereview.chromium.org/2654873006)
  => This issue reproduced.

Checkout https://crrev.com/c9658bbb02f7f6958064bdd2ad8fd8bbb91c771a (the previous revision) and revert the change about native scroll bar (https://codereview.chromium.org/2654873006)
  => This issue did not reproduce.

I'll investigate it further.
Cc: weifangsun@chromium.org
Labels: -ReleaseBlock-Stable -M-62 M-63
It seems this issue is not a new one (occurs since M57 or earlier), and which is caused by a (continuous) performance regression.
The revision I found in comment #6 is the timing that the performance regression hit the threshold on a specific device.

Our scrolling performance has been getting worse gradually.
Now GPU process uses a lot of computing resource, due to relayout/repaint big area unnecessarily while scrolling.

Let me remove the ReleaseBlock label as we have been had this issue for several milestones.
I'll fix the issue as a performance optimization for M63.
Labels: -M-63 M-64
Labels: -M-64 M-65
Labels: -M-65 M-66
Cc: fukino@chromium.org mcirimele@chromium.org
 Issue 765838  has been merged into this issue.
Labels: CrOS-FilesApp
<files-triage>
Labels: -CrOS-FilesApp
Labels: -M-66 M-67
Owner: ----
Status: Available (was: Started)
Labels: -Pri-1 Pri-2
Re-prioritising as P2 for current milestone.
Owner: lucmult@chromium.org
Status: Started (was: Available)
I could not reproduce in a current build.

I'll try in an actual device.
In device I could see the issue, it seems a bit less severe than on the recording, but I'll check further see what I can do there.
Labels: CrOSFilesCategory-Performance
Owner: ----
Status: Available (was: Started)
Labels: -M-67

Sign in to add a comment