New issue
Advanced search Search tips

Issue 637521 link

Starred by 7 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug
M-X

Blocking:
issue 615948
issue 672343


Participants' hotlists:
MacViews-Task-Queue


Sign in to add a comment

ScrollView::ScrollToOffset() shouldn't call OnLayerScrolled() when scrolling with layers

Project Member Reported by tapted@chromium.org, Aug 13 2016

Issue description

Chrome Version       : 52.0.2743.82
OS Version: OS X 10.11.6

ScrollView::ScrollToOffset currently invokes OnLayerScrolled whenever the scroll offset changes. OnLayerScrolled is responsible for updating the position of the header row and scrollbars.

When input events are routed to the cc:InputHandler directly to scroll the layer (also, e.g., for smooth scrolling animations and elasticity rebound), ScrollToOffset isn't invoked and changes go directly to OnLayerScrolled. But this happens asynchronously, and most ScrollView tests don't expect this for things like ScrollRectToVisible.

So for now, OnLayerScrolled will get invoked multiple times each frame if ScrollToOffset is used. ScrollToOffset soon won't be used for the high-throughput trackpad events on Mac since they will get routed to the InputHandler. But for other scrolling codepaths we can save some cycles by not calling OnLayerScrolled in ScrollToOffset, and instead just coalesce everything when the scroll is committed.


context: https://codereview.chromium.org/2188133002/

void ScrollView::ScrollToOffset(const gfx::ScrollOffset& offset) {
  if (ScrollsWithLayers()) {
    contents_->layer()->SetScrollOffset(offset);

    // TODO(tapted): Remove this call to OnLayerScrolled(). It's unnecessary,
    // but will only be invoked (asynchronously) when a Compositor is present
    // and commits a frame, which isn't true in some tests.
    OnLayerScrolled();
  } else {
    contents_->SetPosition(gfx::Point(-offset.x(), -offset.y()));
    ScrollHeader();
  }
}


 
Blocking: 672343
Cc: ellyjo...@chromium.org
Labels: MacViews-Controls
tapted: what's the status of this? Is there remaining work, and if so how important is it?

Comment 3 by tapted@chromium.org, Apr 13 2017

This is an outstanding code health issue and a minor performance nit. It's not blocking anything.
Labels: -MacViews-Controls MacViews-Cleanup
Okay - I've moved this over to Cleanup then.
Labels: M-X
Labels: Group-Architecture
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIToolingRequired
Owner: robliao@chromium.org
Mac triage: to robliao@ for Views triage.
Labels: Hotlist-DesktopUIConsider
Labels: -Hotlist-DesktopUIConsider Hotlist-DesktopUITriaged

Sign in to add a comment