Support updates updates to scroll offset without forcing partial lifecycle updates. |
|
Issue descriptionCurrently, 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).
,
Jan 25 2018
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.
,
Mar 6 2018
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 |
|
Comment 1 by bokan@chromium.org
, Jan 25 2018Status: Available (was: Untriaged)