Branch: refs/heads/safari-7615.1.16.1-branch
Home: https://github.com/WebKit/WebKit
Commit: 84f259c3d8371e4dde443c830ddb8f196045b914
https://github.com/WebKit/WebKit/commit/84f259c3d8371e4dde443c830ddb8f196045b914
Author: Tim Horton <[email protected]>
Date: 2023-01-13 (Fri, 13 Jan 2023)
Changed paths:
M Source/WebCore/platform/graphics/BifurcatedGraphicsContext.cpp
M Source/WebCore/platform/graphics/BifurcatedGraphicsContext.h
M Source/WebCore/platform/graphics/GraphicsContext.h
M Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp
M Source/WebCore/platform/graphics/cg/GraphicsContextCG.h
M Source/WebCore/platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp
M Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.mm
Log Message:
-----------
Cherry-pick 258586@main (7d40f6d46408). rdar://98798050
Canvases painted into CG display list image buffers don't ever update
https://bugs.webkit.org/show_bug.cgi?id=250196
rdar://98798050
Reviewed by Simon Fraser and Dean Jackson.
WebKit has long accidentally depended on the combination of two somewhat
unusual behavioral quirks in CGIOSurfaceContext:
1) (Source) If you make a CGImageRef from one CGIOSurfaceContext via
CGIOSurfaceContextCreateImage, and mutate the original IOSurface under the
hood
(or in a different process) in a way that CGIOSurfaceContext does not know,
CGIOSurfaceContextCreateImage will return the same CGImageRef when called
later.
2) (Destination) If you make a CGImageRef from one CGIOSurfaceContext via
CGIOSurfaceContextCreateImage, paint it into a different CGIOSurfaceContext,
then mutate the original IOSurface, and paint the same CGImageRef again,
the updated IOSurface contents will be used the second time.
The second quirk has never worked with unaccelerated CoreGraphics bitmap
context
destinations. Instead, in the unaccelerated case, the CGImageRef acts as a
snapshot of the surface at the time it was created.
We've long had code to handle this, forcing CGIOSurfaceContextCreateImage to
re-create the CGImageRef each time we paint it (by drawing an empty rect
into
the CGIOSurfaceContext), working around quirk #1 and thus bypassing quirk
#2,
if we're painting into an unaccelerated backing store.
It turns out our CG display list backing store implementation behaves like a
CG bitmap context (without quirk #2), and so currently any IOSurfaces
painted into
CG display list backing store from a CGImageRef created by
CGIOSurfaceContextCreateImage
(but not -CreateImageReference) become stale if painted multiple times.
To avoid this, extend the workaround to apply to any destination context
that
claims that it needs the workaround, and use it whenever painting an
IOSurface
into anything other than a CGIOSurfaceContext.
* Source/WebCore/platform/graphics/BifurcatedGraphicsContext.cpp:
(WebCore::BifurcatedGraphicsContext::needsCachedNativeImageInvalidationWorkaround):
* Source/WebCore/platform/graphics/BifurcatedGraphicsContext.h:
Make BifurcatedGraphicsContext assume the more conservative mode of its two
children.
* Source/WebCore/platform/graphics/GraphicsContext.h:
(WebCore::GraphicsContext::needsCachedNativeImageInvalidationWorkaround):
Assume that by default, GraphicsContexts need the workaround.
* Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp:
(WebCore::GraphicsContextCG::needsCachedNativeImageInvalidationWorkaround):
* Source/WebCore/platform/graphics/cg/GraphicsContextCG.h:
GraphicsContextCG needs the workaround, except in the IOSurface->IOSurface
case.
* Source/WebCore/platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp:
(WebCore::ImageBufferIOSurfaceBackend::finalizeDrawIntoContext):
Confer with the GraphicsContext about its need for the workaround
instead of hardcoding the behavior here.
* Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.mm:
CG display list graphics contexts need the workaround.
Canonical link: https://commits.webkit.org/258586@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 2b6ca2a2e4687b85347e33eb9eb0b113d3e5586b
https://github.com/WebKit/WebKit/commit/2b6ca2a2e4687b85347e33eb9eb0b113d3e5586b
Author: Tim Horton <[email protected]>
Date: 2023-01-13 (Fri, 13 Jan 2023)
Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
Log Message:
-----------
Cherry-pick 258521@main (1a1e7ad8f8a7). rdar://96702143
Live-ish resize sometimes pops to unexpected scroll position even if layout
width doesn't change
https://bugs.webkit.org/show_bug.cgi?id=250153
rdar://96702143
Reviewed by Wenson Hsieh.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _updateScrollViewForTransaction:]):
By default, UIScrollView pins the center of the view when you change
zoomScale.
When doing a live resize with a fixed layout width, the zoomScale changes on
every resize. Resizes normally pin the top edge of the content (or rather,
don't try to adjust the content offset -- at least until scroll anchoring
comes along), so this leads to surprising jumps. To fix this, when
web-process-originated scale changes occur, pin the vertical scroll position
to the top edge of the content, instead of the center. I don't expect any
clients are depending on the existing behavior, and hope that this
will be purely an improvement.
(-[WKWebView _didCommitLayerTree:]):
Like animated resize, bail from updating scroll view parameters and various
other incoming-commit-related things until *after* the live resize finishes.
This avoids us calling _updateScrollViewForTransaction and adjusting
zoomScale
while the resize animation view is installed, which results in our scroll
view
thinking that the current zoomScale is 1, and throwing all the math off,
causing
further unexpected scrolling.
(-[WKWebView _updateVisibleContentRects]):
Fix this logging to indicate whether whether we're deferring geometry
updates
for any reason; an earlier patch changed the condition but not the log.
Canonical link: https://commits.webkit.org/258521@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 68ba9383acdc717014d07c34c6dd3e189ed72d12
https://github.com/WebKit/WebKit/commit/68ba9383acdc717014d07c34c6dd3e189ed72d12
Author: Tim Horton <[email protected]>
Date: 2023-01-13 (Fri, 13 Jan 2023)
Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
Log Message:
-----------
Cherry-pick 258687@main (6e41546bc076). rdar://103977580
REGRESSION (258521@main): Can end up scrolled to an invalid offset, blank
space above page
https://bugs.webkit.org/show_bug.cgi?id=250335
rdar://103977580
Reviewed by Dean Jackson and Megan Gardner.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _updateScrollViewForTransaction:]):
Ensure that we don't scroll to an invalid offset, the same way we do
elsewhere.
Canonical link: https://commits.webkit.org/258687@main
Canonical link: https://commits.webkit.org/[email protected]
Compare: https://github.com/WebKit/WebKit/compare/b04e12775477...68ba9383acdc
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
