New issue
Advanced search Search tips

Issue 803947 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Support updates updates to scroll offset without forcing partial lifecycle updates.

Project Member Reported by chrishtr@chromium.org, Jan 19 2018

Issue description

Currently, programmatic updates to scroll offset via script plus
methods on Element or DOMWindow force layout before applying the
scroll offset, because otherwise clamping of the scroll offset
cannot be computed.

The code also schedules a new frame, which is when the scroll is really
applied and drawn to the screen.

Instead, we should implement such methods by mutating something like
a PendingScroll object, dirtying scroll/layout state, and requesting
a frame update. then when the new frame is generated, layout will happen
and the PendingScroll will be turned into a real scroll.

This allows developers to write scroll state without forced layouts
outside of frame generation, thus improving performance and becoming
compatible wit efforts to understand and control frame generation
for performance and scalability (async dom, throttling, etc).
 

Comment 1 by bokan@chromium.org, Jan 25 2018

Cc: bokan@chromium.org skobes@chromium.org
Status: Available (was: Untriaged)
This sounds good to me. Was there a motivating use-case for this? Also, is this part of the slimming paint critical path or is it low-urgency? This sounds like something that'd be easier to do after root-layer-scrolls ships.
The motivating use-case is a framework which manipulates scroll offsets as well as
layout. The framework should be able to set any scroll offsets plus layout, and
expect exactly one rendering update to occur.

This is not extremely high priority, but is one blocker for a saner and jank-free
lifecycle story. It does not block Slimming Paint.
Related issue:  420741 . There is also a comment in Element.cpp referring
to that bug:

// FIXME: This should be removed once scroll updates are processed only after
// the compositing update. See  http://crbug.com/420741 .

Sign in to add a comment