Horrible jank in Google Sheets
Reported by
e...@mention-me.com,
May 24 2018
|
|||||||
Issue descriptionChrome Version : 66.0.3359.181 OS Version: OS X 10.11.6 URLs (if applicable) : docs.google.com/spreadsheets Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari: OK Firefox: OK IE/Edge: N/A Chrome, Incognito, No Extensions: Fail What steps will reproduce the problem? 1. Load a Google Sheet, of any volume. 2. Wait for the initial load to complete (i.e. "Working" butter bar and chrome UI disappears) 3. Do any of the following: Scrolling (up/down, left/right), try and edit a field or navigate. What is the expected result? Smooth scrolling What happens instead of that? Horrific jank. The Chrome Performance tab shows "Composite Layers" is taking up ~200 ms, and only pausing occasionally to run other code (which executes relatively quickly). I've included a trace from the Chrome Profiler. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
,
May 24 2018
As per the trace the time is spent in RasterTask via TaskGraphRunner::RunTask. See if the bug is fixed by changing chrome://flags/#enable-gpu-rasterization
,
May 24 2018
It's set to "Default". Disabling it does not appear to make any difference. Enabling it doesn't exactly go well as per the screenshot.
,
May 24 2018
,
May 28 2018
Unable to reproduce the issue on chrome reported version using Mac 10.12.6 with steps mentioned below: 1) Launched chrome reported version and navigated to URL: docs.google.com/spreadsheets 2) Opened blank page, scrolled (up/down, left/right), edited the field, able to do all the actions without any issues @Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging. Thanks!
,
May 29 2018
@viswa, that's exactly right. I get a different experience sadly :( I've attempted to narrow the problem down a bit further. It appears to only occur when I've got an external monitor plugged in, and it only seems to occur at certain screen sizes. Please see the attached video which shows scrolling fine when at a small window size, but as soon as it's made bigger scroll performance drops through the floor. Looking at the profiler, it shows compositing taking ~50ms in the smaller window and ~120ms in the larger window. Out of curiosity, I tried a few other applications, e.g. Microsoft Excel (not the web version, the installed version), and various other web apps (e.g. a Google Doc with ~30 pages in) and those are both fine. Any ideas on anything else I can do to try and identify a cause?
,
May 29 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 30 2018
Unable to reproduce the issue on chrome reported version 66.0.3359.181 and on latest stable# 67.0.3396.62 using Mac 10.12.6/10.13.3 with steps mentioned below: 1) Launched chrome reported version and navigated to URL: docs.google.com/spreadsheets 2) Opened blank page, scrolled (up/down, left/right), edited the field Observations: Even tried by checking as steps mentioned in comment#6 by scrolling and typing in the page by changing the size of the window, able to do all the actions without any issues @Reporter: Could you please try to test this issue on latest stable and let us know if the issue still persists. You can download latest chrome stable from URL: https://www.chromium.org/getting-involved/dev-channel. Thanks!
,
Jun 5 2018
I am now unable to reproduce this myself before upgrading. I've also upgraded to 67.0.3396.62 and also unable to replicate it there either. I'd be content with this issue being closed.
,
Jun 5 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 6 2018
As per comment#9 by reporter the issue no longer seems to be reproducible from his end, as per the confirmation in C#9 closing this issue marking it as Won't fix. Thanks! |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 Deleted