MacViews: Touchpad scroll gestures are not smooth |
|||||||
Issue descriptionChrome Version : 50.0.2661.18 OS Version: OS X 10.11.3 What steps will reproduce the problem? 1. chrome://flags/#mac-views-dialogs enabled 2. Bookmark -> Edit... -> Mash 'New Folder' a bunch to get a scrollable view 3. Scroll with a touch pad What is the expected result? Scrolling should be buttery smooth What happens instead of that? It kinda jerks around a bit. It's like this in m48 as well, but I'm not sure if it always was this bad... Clicking the scrollbar thumb and dragging scrolls quickly and is quite smooth. I think the issue is that scrolling with the touchpad generates a *lot* more events - more than in other toolkit-views platforms - and too much is getting invalidated in the view layout, or too much is getting redrawn. Or something. Composited scrolling will fix this, but there might also be scope for some performance tweaks for views::ScrollView. Alternatively, some kind of "backpressure" to collapse multiple scroll updates into one event with an accumulated offset.
,
Apr 20 2016
,
May 31 2016
,
May 31 2016
,
Jul 15 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 5 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b7720c4c053a09050c9abab73b0af528150dd42c commit b7720c4c053a09050c9abab73b0af528150dd42c Author: tapted <tapted@chromium.org> Date: Fri Aug 05 07:17:15 2016 MacViews: Claim -[NSView isOpaque] for the content view according to the root layer properties. Once we start scrolling with Layers, most of the CPU taken up when scrolling is actually taken up by redrawing the window frame. This is because BridgedContentView currently always claims that it is transparent. So, when paint areas are invalidated, AppKit must first ask the window frame to redraw that region in case BridgedContentView wants to draw something transparent on top of that. For opaque windows, none of the window background shows through, so report YES from -[NSView isOpaque] in those cases. BUG= 594907 , 605131 Review-Url: https://codereview.chromium.org/2219663003 Cr-Commit-Position: refs/heads/master@{#410012} [modify] https://crrev.com/b7720c4c053a09050c9abab73b0af528150dd42c/ui/views/cocoa/bridged_content_view.mm [modify] https://crrev.com/b7720c4c053a09050c9abab73b0af528150dd42c/ui/views/widget/native_widget_mac_unittest.mm
,
Aug 13 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e commit 4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e Author: tapted <tapted@chromium.org> Date: Sat Aug 13 09:09:32 2016 Scroll with Layers in views::ScrollView Initially, do this only on Mac, or with --enable-features=ToolkitViewsScrollWithLayers. This is a first step for bringing up elastic scrolling of a views::ScrollView on Mac. Still, by itself, it results in significant performance improvements for scrolling in toolkit-views and allows the UI thread to keep pace with the high rate of touchpad scroll events produced by Cocoa on Mac. To take advantage of existing scroll handling for smooth-scrolling and elasticity, later CLs will route scroll events through the cc::InputHandler (i.e. LayerTreeHostImpl). Since the ui::Compositor is single-threaded on the UI thread, there is no distinct impl side. For a consistent event flow, perform all scrolling on the impl side. This requires plumbing through a way for a views::ScrollView to set the scroll offset on the impl side directly, in response to an input event. views::ScrollView now makes its contents layer-backed and clips it to the layer added to the existing ScrollView viewport. BUG=615948, 594907 , 605131 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2188133002 Cr-Commit-Position: refs/heads/master@{#411889} [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/cc/input/input_handler.h [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/cc/trees/layer_tree_host_impl.h [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/cc/trees/single_thread_proxy.cc [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/chrome/browser/ui/views/extensions/extension_install_dialog_view.cc [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/chrome/browser/ui/views/extensions/extension_install_dialog_view.h [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/compositor/compositor.cc [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/compositor/compositor.h [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/compositor/layer.cc [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/compositor/layer.h [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/events/blink/input_handler_proxy_unittest.cc [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/views/controls/scroll_view.cc [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/views/controls/scroll_view.h [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/views/controls/scroll_view_unittest.cc [modify] https://crrev.com/4b70c528d7a6652e534bc5d9efd19d2d57d3fe4e/ui/views/view.cc
,
Aug 15 2016
,
Aug 16 2016
tapted@ : Could you please help if it can be verified from TE end and so please provide the steps to verify the same. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by tapted@chromium.org
, Apr 14 2016