Issue metadata
Sign in to add a comment
|
Scrolling lags to a crawl while scrolling up on GitHub's code diffs
Reported by
kamranm...@gmail.com,
Aug 12
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3520.0 Safari/537.36 Example URL: https://github.com/python-telegram-bot/python-telegram-bot/commit/9f2806e170632bd354c8a79d32e46719f7996fd3 Steps to reproduce the problem: 1. Go to a site with a lot of content, such as GitHub code diffs. 2. Start scrolling down, and then after a bit of scrolling, attempt to scroll up rapidly. 3. While scrolling up rapidly, the browser will slow down to an absolute crawl. Scrolling down does not have this issue. What is the expected behavior? The expected behavior is that scrolling up would be the same level of performance as scrolling down, but at the moment it is not. What went wrong? The Chrome renderer cannot seem to handle the rapid pace of scrolling offered by certain kinds of mice, such as the Logitech G502. However, I have also noticed that even when scrolling up at a decent pace, the browser slows down a bit as well, just not as much as when scrolling up rapidly. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 70.0.3520.0 Channel: canary OS Version: 10.0 Flash Version: 31.0.0.89 I should note: This issue only appears to happen on GitHub. The same issue does not occur on another code sharing site, known as GitLab.
,
Aug 12
Yikes, just want to make a slight update: I accidentally selected "Yes" on the multiple sites question. That should actually be a no. Also, for clarity, I just wanted to attach my system specs below. System specs: OS: Windows 10 Professional 64-bit CPU: AMD Ryzen 7 1700 @ 3.8GHz GPU: NVIDIA GeForce GTX 1080 RAM: 16GB DDR4 RAM @ 3200MHz
,
Aug 13
Thank you for reporting this issue to us. Not sure if this is scroll or events, but 70.0.3520.0 seems worse than 68.0.3440.106 for the reported page.
,
Aug 13
Able to reproduce the issue on reported chrome version 70.0.3520.0 and on beta# 69.0.3497.32 using Windows-10, Mac 10.12.6 & Ubuntu 14.04 hence providing Bisect Info Note: Issue is not seen on 68.0.3440.106 Bisect Info: ================ Good build: 69.0.3475.0 Bad build: 69.0.3476.0 You are probably looking for a change made after 571250 (known good), but no later than 571251 (first known bad). https://chromium.googlesource.com/chromium/src/+log/35bea100681d5c1268ec075ba83f715163107cb1..f0498e2265442349ed2b837c09631fb3b9eb237c Change-Id: I08e3a1f8883584b3a30c4dfa498489df64be012c Reviewed-on: https://chromium-review.googlesource.com/1117712 @Xianzhu Wang: Please confirm the issue and help in re-assigning if it is not related to your change. Adding ReleaseBlock-Stable as it is seems a recent break, feel free to remove it if not applicable. Thanks!
,
Aug 13
,
Aug 13
M69 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Aug 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/962c6b2894c7292ffa01263cf40346659abe1bcd commit 962c6b2894c7292ffa01263cf40346659abe1bcd Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Tue Aug 14 16:09:23 2018 [PE] Fix performance issue in PaintController::FindOutOfOrderCachedItemForward() I missed update of next_item_to_index_, causing cached items after next_item_to_index_ to be added into index repeatedly for each new valid item inserted. (This is not a new regression but exposed by crrev.com/571251 in more cases especially during upward composited scrolling when display items newly appearing in the new interest rect are inserted in front of other cached items. Before that CL the newly appearing display items were treated as not cached because of their cache generation mismatching the paint controller's. After that CL we call FindOutOfOrderCachedItemForward().) Bug: 873511 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I17bc3ee55ad678f968ac8d9904fbc6a9b087407f Reviewed-on: https://chromium-review.googlesource.com/1173405 Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#582929} [modify] https://crrev.com/962c6b2894c7292ffa01263cf40346659abe1bcd/third_party/blink/renderer/platform/graphics/paint/paint_controller.cc [modify] https://crrev.com/962c6b2894c7292ffa01263cf40346659abe1bcd/third_party/blink/renderer/platform/graphics/paint/paint_controller_test.cc
,
Aug 14
This issue appears to be fixed in the latest Chromium build available on the https://download-chromium.appspot.com site. Thanks for fixing this so quickly!
,
Aug 14
Pls update bug with canary result tomorrow and request a merge to M69 if change looks good in canary/safe to merge.
,
Aug 15
The NextAction date has arrived: 2018-08-15
,
Aug 15
Verified on Canary 70.0.3523.0. The CL is quite safe to merge.
,
Aug 15
This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 15
Approving merge to M69 branch 3497 based on comment #11. Please merge ASAP. Thank you.
,
Aug 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/834da117321c0ba10dafc341d5d400131e154d5d commit 834da117321c0ba10dafc341d5d400131e154d5d Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Wed Aug 15 17:20:29 2018 [PE] Fix performance issue in PaintController::FindOutOfOrderCachedItemForward() I missed update of next_item_to_index_, causing cached items after next_item_to_index_ to be added into index repeatedly for each new valid item inserted. (This is not a new regression but exposed by crrev.com/571251 in more cases especially during upward composited scrolling when display items newly appearing in the new interest rect are inserted in front of other cached items. Before that CL the newly appearing display items were treated as not cached because of their cache generation mismatching the paint controller's. After that CL we call FindOutOfOrderCachedItemForward().) TBR=wangxianzhu@chromium.org (cherry picked from commit 962c6b2894c7292ffa01263cf40346659abe1bcd) Bug: 873511 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I17bc3ee55ad678f968ac8d9904fbc6a9b087407f Reviewed-on: https://chromium-review.googlesource.com/1173405 Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#582929} Reviewed-on: https://chromium-review.googlesource.com/1176104 Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/branch-heads/3497@{#642} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/834da117321c0ba10dafc341d5d400131e154d5d/third_party/blink/renderer/platform/graphics/paint/paint_controller.cc [modify] https://crrev.com/834da117321c0ba10dafc341d5d400131e154d5d/third_party/blink/renderer/platform/graphics/paint/paint_controller_test.cc
,
Aug 15
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 Deleted