Changes between Initial Version and Version 1 of WhatsChangingwithscrollingonmacOS


Ignore:
Timestamp:
Jan 5, 2021 3:17:35 PM (3 years ago)
Author:
Jon Davis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WhatsChangingwithscrollingonmacOS

    v1 v1  
     1== What’s changing with scrolling on macOS ==
     2''by Simon Fraser (Apple)''
     3
     4An update on scrolling.
     5
     6''Simon:'' Talking about scrolling changes. Working on specifically macOS. Hopefully none of this is from last year.
     7
     8''Simon:'' Talking about overflow scrolling sync and then a more recent (Safari only for now) thats about more asynchronous scrolling
     9
     10''Simon:'' Overflow scroll Async is scrolling overflow areas on the scrolling thread, which means that even if JS or other things are on the main thread, you still get some scrolling.
     11
     12''Simon:'' We have a scrolling tree, which is the tree of nodes that represents a scrollable area.
     13
     14''Simon:'' ''For the longest time you could set scrolling:'' touch and then you would get fast overflow scrolling with the side effect of creating a stacking context. We wan't to implement this on Mac without this quirk. This involved being able to determine what is under the cursor off of the main thread.
     15---
     16''Simon:'' An element that has rounded corners needs hit test to ignore those corners.
     17
     18''Simon:'' We build this region using a fake paint.
     19
     20''Simon:'' On Mac this is used for interative region and wheel event listeners.
     21
     22Simon:On iOS used touchAction CSS property.
     23
     24''Simon:'' Third use is editabe regions.
     25
     26''Simon:'' We have good impl of event loop in Page.
     27
     28''Simon:'' We build these event regions once per frame.
     29
     30''Simon:'' Updated in render layer backing by a fake paint.
     31
     32''Simon:'' Instead of drawing, we build the even region in a dummy graphics context.
     33
     34''Simon:'' Event region is the union of the fake painting, taking care of rounded corners and other cases.
     35
     36''Simon:'' Better than finding event handlers and regions - this is more performant and more accurate since it matches painting.
     37
     38''Simon:'' We use fake regions for interactive region, touch action, wheel events, and editable content.
     39
     40''Simon:'' [Showing example] It's fine if we overestimate region, not good if we underestimate.
     41
     42''Simon:'' Blue overlay is showing the region that is interactive.
     43
     44''Simon:'' That's how we do hit testing off the main thread.
     45
     46''Simon:'' Additional compositing complexity on Mac.
     47
     48''Simon:'' CSS is crazy. We have containing block hierarchy, but for z-order tree to build CALayerTree.
     49
     50''Simon:'' We have to represent the clipping to do clipping through CA.
     51
     52''Simon:'' This isn't all the time, but it does need taken care of.
     53
     54''Simon:'' We have to represent overflow scroll clipping in the z-order.
     55
     56''Simon:'' It's possible for elements to sit ontop of the scroll bar, so the scroll bar has to be it's own layer on the Mac.
     57
     58''Simon:'' We end up with crazy clipping order because of this.
     59
     60''Simon:'' On the Mac you now always get async scrolling unless you have fixed background or wheel event listeners.
     61
     62''Simon:'' Scroll sync.
     63
     64''Simon:'' Mac had worse behavior with things that behaved worse like fake position, sticky position, fixed.
     65
     66''Simon:'' In old world, wheel events went to Event dispatcher thread.
     67
     68''Simon:'' Event dispatcher thread sends those to the scrolling thread.
     69
     70''Simon:'' [Showing diagram] This is three frames, but wheel events don't match rendering frequency in all cases.
     71
     72''Simon:'' Immediately adjusted CALayer positions and flush changes to screen.
     73
     74''Simon:'' Meanwhile main thread is running it's rendering update cycle.
     75
     76''Simon:'' Main thread has it's own notion of where layers are. Happens every frame.
     77
     78''Simon:'' What shows up on the screen was the last thing commited.
     79
     80''Simon:'' On the first frame, that's the render, on the second frame thats the scrolling.
     81
     82''Simon:'' There was a worse problem.
     83
     84''Simon:'' We only tell the main thread that things have changes asynced, so the main thread could have stale state mid-frame.
     85
     86''Simon:'' ''Guaranteed main thread would be stale re:'' visible scroll position.
     87
     88''Simon:'' Fixing this required...
     89
     90''Simon:'' Scrolling thread needs to know when rendering updates will be triggered.
     91
     92''Simon:'' Display refresh now notifies scrolling thread which then notifies main thread.
     93
     94''Simon:'' Main thread tells scrolling thread when it starts and finishes working.
     95
     96''Simon:'' Scrolling thread can avoid a commit this way.
     97
     98''Simon:'' ''The good case:'' Main thread responsive. Main thread synchronously fetches scrolling state from scrolling thread.
     99
     100''Simon:'' Scrolling thread then waits for main thread.
     101
     102''Simon:'' When main thread is done, it does a CACommit and unlocks the scrolling thread.
     103
     104''Simon:'' This can go bad...
     105
     106''Simon:'' Long request animation frame.
     107
     108''Simon:'' Scrolling thread will time out waiting for the main thread to ensure fast async scrolling if the main thread is behind.
     109
     110''Simon:'' In that case scrolling thread does trigger rendering.
     111
     112''Simon:'' Unresponsive main thread falls back to allowing the scrolling thread to commit frames.
     113
     114''Simon:'' [Demo]
     115
     116''Simon:'' This old version of Safari shows the bug.
     117
     118''Simon:'' This content is scrollable, and we have two boxes to move around, on that is position fixed, the other is fake fixed (on scroll it moves).
     119
     120''Simon:'' Main thread is responsive in this case.
     121
     122''Simon:'' Even so, with the fake fixed we don't keep the fake fixed element in one position while scrolling.
     123
     124''Simon:'' When fixed, the orange box is almost always in the right place (much better).
     125
     126''Simon:'' If we force random blocks on the main thread, we see it falls back and behaves as it did before.
     127
     128''Simon:'' Okay, that's scroll synchronization.
     129
     130''Simon:'' More features for scroll performance...
     131
     132''Simon:'' ''Wheel event handlers:'' There is an option to make event listeners passive. Acknowledge that preventDefault won't be called.
     133
     134''Simon:'' If your pointer is in a region with only passive listeners, we stay on the fast-path for scrolling.
     135
     136''Simon:'' Previously this wasn't the case.
     137
     138''Simon:'' Any region with event handlers followed the slow path before.
     139
     140''Simon:'' One note is that many sites used event handlers to track user behavior.
     141
     142''Simon:'' We had to add code to collect active and passive event handlers.
     143
     144''Simon:'' We track these regions all the way through to the event regions, letting us stay on the fast path more often.
     145
     146''Simon:'' This fixes Reddit.
     147
     148''Simon:'' We now hit the fast path for Reddit.
     149
     150''Simon:'' A few WIP fixes...
     151
     152''Simon:'' If the page registers wheel event handlers on the root, make them passive by default (like Blink has been doing).
     153
     154''Simon:'' We already do this for touch event handlers on iOS.
     155
     156''Simon:'' This makes Twitter faster.
     157
     158''Simon:'' Chrome also has a behavior where the first event in a gesture is not prevent-defaulted, none of the events in that sequence will be cancellable.
     159
     160''Simon:'' This matches Blink.
     161
     162''Simon:'' The spec is vague regarding this. Hoping now web-compat issues.
     163
     164== Questions & Comments ==
     165
     166''Nikolas:'' There is interest in this. I haven't had a look at it, but I liked this nice overview. Very nice.
     167
     168''Alexg:'' This is one of our goals for the next months. We have issues on mostly embedded devices with scrolling. We are working on it and very interested in any improvements. Awesome talk.