Since we now have other notions of visibility that are updated both faster and more cheaply (during each paint, i.e. every 16ms if something has changed), there is now less of a need for immediate approximate frame visibility updates. Approximate frame visibility at this point is mainly used for predictive image decoding, and that's something that we can afford to update more slowly. Also, by eliminating the cases where we force approximate frame visibility to be updated *immediately*, we can drastically simplify the heuristics we use to update it, since their complexity mainly comes from a desire to reduce the number of approximate frame visibility updates we do.
It should be noted what the tradeoffs here are, though. The main thing we'd do in this bug is update approximate image visibility at most every second, as opposed to potentially much more frequently, whenever scroll positions or display port margins change substantially. Which approach is better is complicated to evaluate. Here are the tradeoffs for each approach: If we update approximate frame visibility immediately when scroll state changes: - We get a head start on predictive decoding of images, possibly before the next paint, since usually the event that does the update will propagate through the event loop faster than the 16ms between refresh driver ticks. - We'll potentially spend more time on display list building and painting if we don't trigger a decode until in-displayport or in-viewport visibility is updated, because we may trigger a paint before we've completed decoding some of the newly visible images, which means we'll have to do a second paint later. Obviously this doesn't really matter for images which get an active ImageLayer or cases where we can efficiently do a repaint of just the image. If we update approximate frame visibility at most once per second: - We spend less CPU time on frame tree walks, since other notions of visibility are updated very cheaply and the frame tree walks to update approximate frame visibility can be triggered more than once per refresh driver tick. - At the next refresh driver tick, when we update in-displayport and/or in-viewport visibility, we'll trigger decoding for the small set of images that are actually visible to the user. This means that those decodes will take priority, which may make for a better user experience. It's frankly a bit difficult to evaluate the relative costs of these two options; before landing this change we should look at Talos results.