[webkit-changes] [WebKit/WebKit] 7d40f6: Canvases painted into CG display list image buffer...

[Tim Horton]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7d40f6d464086a0a19ec87115cbd5f4d1bff740c
      https://github.com/WebKit/WebKit/commit/7d40f6d464086a0a19ec87115cbd5f4d1bff740c
  Author: Tim Horton <thorton at apple.com>
  Date:   2023-01-06 (Fri, 06 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:
  -----------
  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