commit ec36eefa5d9f4706d984c08d74a89c775a6e6843
author Matt Woodrow <mattwoodrow@apple.com> Wed May 14 01:50:27 2025
committer Matt Woodrow <mattwoodrow@apple.com> Wed May 14 01:50:27 2025
tree 61f02b3a13b574fda4198e6c1e8cf1ed89c48eea
parent 87cce29e4be749a0b851263fdca88aac03535b75

REGRESSION (281042@main): [ macOS ] 2x tiled-drawing/scrolling/overflow/overflow-scrolled-* are flaky failing.
https://bugs.webkit.org/show_bug.cgi?id=277109
<rdar://132528380>

Reviewed by Simon Fraser.

The regressing change here allowed
RenderLayerBacking::adjustTiledBackingCoverage to succeed, even if the
underlying GraphicsLayer hadn't yet allocated a TileController (which happens
during the rendering update layer flush), and exposed existing races in these
tests.

This converts HistoricalVelocityData to use a Deque with inline capacity rather
than manually managing a std::array circular buffer. This should be
functionally identical, but removes a bunch of complexity from this class.

It also removes the filtering/coalescing of updates from this class. The
existing comment suggested that this previously many times per frame, but that
appears to no longer be the case. It looks like the only callers are from a
CATransaction pre-commit handler, and from Page::updateRendering (and flushing
layers from the test harness). It should be ok to adds a new entry for each of
these instances.

This fixes a race with the test, where requestAnimationFrame/updateRendering
isn't guaranteed to be exactly 1/60th of a second apart (and is frequently
less, since we run the first instance after idle immediately, not waiting for
vsync). We now get a computed velocity in this case, rather than leaving it
blank. There also was the issue where the code filtered on exactly 1/60th of a
second, and vsync aligned callbacks (with any amount of variance) would often
be ever-so-slightly under that.

Finally, use the same MonotonicTime timestamp for both velocityForNewData and
adjustTileCoverageWithScrollingVelocity (on mac, iOS uses the
m_haveExternalVelocityData path). These previously used separate calls to
::now(), resulting in the futureRect being moved by tiny amounts (unlikely to
be useful, but causes test failures).

It's plausible that in the future we would want instead to use a useful
timeDelta (maybe a vsync duration) in this case, to predict where future
scrolling might end up, instead of just adding a single tile in the scrolled
direction.

* LayoutTests/platform/mac-wk2/TestExpectations:
* LayoutTests/tiled-drawing/scrolling/overflow/overflow-scrolled-down-tile-coverage-expected.txt:
* LayoutTests/tiled-drawing/scrolling/overflow/overflow-scrolled-up-tile-coverage-expected.txt:
* Source/WebCore/platform/graphics/VelocityData.cpp:
(WebCore::HistoricalVelocityData::velocityForNewData):
* Source/WebCore/platform/graphics/VelocityData.h:
(WebCore::HistoricalVelocityData::clear):
* Source/WebCore/platform/graphics/ca/TileController.cpp:
(WebCore::TileController::adjustTileCoverageWithScrollingVelocity const):
(WebCore::TileController::adjustTileCoverageRectForScrolling):
* Source/WebCore/platform/graphics/ca/TileController.h:

Canonical link: https://commits.webkit.org/294876@main