Bug 237113 – REGRESSION (iOS 15.4 beta) - WebGL yields incorrect results when using preserveDrawingBuffer on iOS 15.4 Beta

• Component: WebGL
• Status: RESOLVED FIXED

[Christoph Bartschat]

This is a regression between iOS 15.3.1 and 15.4.

It appears that preserveDrawingBuffer is not taking effect. When we render a three.js scene with:

const context = canvas.getContext('webgl', {preserveDrawingBuffer: true})
...
renderer.autoClear = false

We expect that each frame is rendered on top of the previous frame, without replacing it.

However, as can be see in this demo: https://codepen.io/cmb8/pen/bGYKPrP

We should see a check mark getting drawn, but instead, we only see the circle moving across the
screen, without leaving a trail.

The problem occurs for both 'webgl' and 'webgl2' in the getContext call.

Disabling "WebGL via Metal" in "Experimental WebKit Features" and relaunching Safari 
fixes the behavior.


Video of expected behavior: https://youtu.be/4EpijoQe_Kw

Video of unexpected behavior: https://youtu.be/YHNgSRgy8ag

[Radar WebKit Bug Importer]

<rdar://problem/89382320>

[Kenneth Russell]

This can actually be reproduced in Safari Technology Preview Release 140 (Safari 15.4, WebKit 17614.1.1.5) on M1 hardware, making it easier to diagnose.

I wonder whether the ANGLE roll in Bug 235746 will affect this behavior - somewhat doubt it if this is a WebKit-side change.

[Kenneth Russell]

Note that this doesn't reproduce in the same version of Safari Technology Preview on Intel hardware.

[Kimmo Kinnunen]

ANGLE roll in Bug 235746 does not fix this issue.

[Kimmo Kinnunen]

Bisection initially points to r286645 bug 233977

[Kimmo Kinnunen]

Scratch that, second initial bisection points to bug 220896  r286603

[Kimmo Kinnunen]

Bug 235746 fixes https://greggman.com/downloads/examples/webgl/lessons/resources/webgl-preservedrawingbuffer-true.html

Does not fix https://codepen.io/cmb8/pen/bGYKPrP

[Kenneth Russell]

This bug reproduces in Chromium, too, when using the ANGLE/Metal backend on M1 hardware. I used the tools to run a bisect there:

./src/tools/bisect-builds.py -a mac-arm -g 874000 -b 974000 --use-local-cache --verify-range -- --no-first-run --use-cmd-decoder=passthrough --use-angle=metal https://codepen.io/cmb8/pen/bGYKPrP

which turned up:

You are probably looking for a change made after 901356 (known good), but no later than 901367 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/047f67dec3ae1322e17a408954b12bf0e000a433..5eca15b4748370af38b90b98314d84523af8c6ba

containing the ANGLE roll in which Apple's direct-to-Metal translator first began upstreaming last July:

https://chromium.googlesource.com/chromium/src/+/3fc5546c60cfc7db7b3cf8c0d0c0ccf16927c850
https://chromium.googlesource.com/angle/angle.git/+log/b7cfbac4f8c5..2a668d9219dd

so unfortunately this bug crept in a while ago and there's no fine-grained way to track it down. It probably occurred in this large patch:

https://chromium-review.googlesource.com/c/angle/angle/+/2950067

and the reason this is showing up in 15.4 is that contains the ANGLE roll into WebKit from last December, Bug 220896.

[Kenneth Russell]

Looking through that patch, I doubt this is the problem but perhaps you'd like to try taking out the EXT_multisampled_render_to_texture code path on iOS as well:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/angle/src/libANGLE/renderer/metal/DisplayMtl.mm;l=907?q=DisplayMtl.mm

[Kenneth Russell]

The work-in-progress fix https://chromium-review.googlesource.com/c/angle/angle/+/3465937/ doesn't fix this either on the M1.

[Kenneth Russell]

This is almost surely a regression in the MTLStoreAction used to resolve the multisampled framebuffer; the multisampled contents have to be preserved after the blit to resolve, unless discarded. Can this be investigated from that standpoint?

[Kenneth Russell]

A note that there's a fix in review in upstream ANGLE which may fix this:
https://chromium-review.googlesource.com/c/angle/angle/+/3506089

[Kenneth Russell]

gman@'s upstream fix in ANGLE is confirmed to fix this bug:
https://chromium-review.googlesource.com/c/angle/angle/+/3506089

[Kimmo Kinnunen]

Created attachment 454467 [details]
Patch

[Kimmo Kinnunen]

Created attachment 454468 [details]
Patch

[EWS Watchlist]

Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE

[Myles C. Maxfield]

Comment on attachment 454468 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=454468&action=review

> Source/ThirdParty/ANGLE/ChangeLog:17
> +        https://www.khronos.org/registry/webgl/sdk/tests/conformance2/renderbuffers/multisample-draws-between-blits.html

Does this patch enable the test somehow?

[Kimmo Kinnunen]

(In reply to Myles C. Maxfield from comment #17)
> Comment on attachment 454468 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=454468&action=review
> 
> > Source/ThirdParty/ANGLE/ChangeLog:17
> > +        https://www.khronos.org/registry/webgl/sdk/tests/conformance2/renderbuffers/multisample-draws-between-blits.html
> 
> Does this patch enable the test somehow?

No, tests need to be rolled from the conformance test repo.

[EWS]

Committed r291218 (248373@main): <https://commits.webkit.org/248373@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 454468 [details].

[Anna from Mapbox]

Hi all, is this fix going to be released in a patch for 15.4? It there a way to test this fix in a beta version? We have a similar problem: https://bugs.webkit.org/show_bug.cgi?id=237918. Thanks!

[Kyle Piddington]

I can confirm that on iOS, (In reply to Anna from Mapbox from comment #20)
> Hi all, is this fix going to be released in a patch for 15.4? It there a way
> to test this fix in a beta version? We have a similar problem:
> https://bugs.webkit.org/show_bug.cgi?id=237918. Thanks!

Hi Anna,
I can't comment on when this fix will show up on iOS, but I can confirm that on iOS, this patch fixes your Mapbox regression. I'll make sure to mirror this information on your bug report.

[Kimmo Kinnunen]

*** Bug 237918 has been marked as a duplicate of this bug. ***

[Anna from Mapbox]

(In reply to Kyle Piddington from comment #21)
> I can confirm that on iOS, (In reply to Anna from Mapbox from comment #20)
> > Hi all, is this fix going to be released in a patch for 15.4? It there a way
> > to test this fix in a beta version? We have a similar problem:
> > https://bugs.webkit.org/show_bug.cgi?id=237918. Thanks!
> 
> Hi Anna,
> I can't comment on when this fix will show up on iOS, but I can confirm that
> on iOS, this patch fixes your Mapbox regression. I'll make sure to mirror
> this information on your bug report.

Thanks Kyle for digging into this! We were able to do a patch release last week that disables antialiasing for 15.4 Safari to resolve this problem on our end. We found it reproducible in iOS 15.4 devices and M1 Macbooks.

[Anna from Mapbox]

Hey all, so this issue is also happening for us on M1 Macbooks. We tested the newly released Safari Technology Preview Release 142 (Safari 15.4, WebKit 16614.1.5.16) on an M1 Mac and still see this issue. There isn't an iOS beta out yet to test on iOS. Does/Can this solution also apply to Safari (non iOS)? Thanks! Here's the jsbin example: https://jsbin.com/mojuyosenu/edit?html,css,js,output

[Dean Jackson]

(In reply to Anna from Mapbox from comment #24)
> Hey all, so this issue is also happening for us on M1 Macbooks. We tested
> the newly released Safari Technology Preview Release 142 (Safari 15.4,
> WebKit 16614.1.5.16) on an M1 Mac and still see this issue. There isn't an
> iOS beta out yet to test on iOS. Does/Can this solution also apply to Safari
> (non iOS)? Thanks! Here's the jsbin example:
> https://jsbin.com/mojuyosenu/edit?html,css,js,output

I think it will be in the next Safari Technology Preview. Sorry, it hasn't been updated in a while.

[Brent Fulgham]

This fix shipped with Safari 15.5 (all platforms).

[Brent Fulgham]

*** Bug 237230 has been marked as a duplicate of this bug. ***