Created attachment 454724 [details] Video of the bug taking place on MacOS using Safari 15.4 Our WebGL game renders completely broken in iOS 15.4, and Safari 15.4 on MacOS, where WebGL on Metal is enabled. Disabling WebGL on Metal makes the game render correctly. It seems to render a whole block of old render commands either constantly, or every other frame. We haven't been able to nail down a minimal repro yet, but it affects such massive amounts of our code that it has to be something fundamental - command buffers being incorrectly updated or something. You can test it at this URL, but it'll probably break in a day or two when we do a new release - https://play.skyweaver.net/game/dc1e1b2a35b17c9238e452071722f0208636e72c/?mode=LOCAL_BOT You can make an account and play a "practice" game here, at https://play.skyweaver.net , which will always reproduce the error. Let me know if I can help further.
A little more info - this happens when using both WebGL 1 and WebGL 2.
More info - happens only on iDevices, and Apple Silicon devices. Doesn't happen on Intel Macbooks.
Thank you for the report. Unfortunately there is at least one high impact regression, bug 237113. This affects multisample rendering with preserveDrawingBuffer == true. I could not immediately start a practice mode -- the game did not manage to connect and the link did not work. If the game uses preserveDrawingBuffer == true, you may experiment working around the issue by turning it false if this is possible with the game..
Here's another link, but this will stop working in a day or two, probably: https://play.skyweaver.net/game/f8bba5414700a7817c35595960e925ea9cee4267/?mode=LOCAL_BOT We don't use preserveDrawingBuffer === true.
We've investigated further - the bug seems to be primarily related to rendering to a WebGL Offscreen buffer, then rendering to the screen. We've now managed to make it happen with both WebGL on Metal enabled *AND* disabled.
<rdar://problem/90333435>
Is it possible for you to provide a more reduced test case than the entire game? I tried logging in to the game via a Google account and starting the tutorial, but it got into an infinite reload loop, apparently while trying to play the introductory video. This was on ChromeOS - not macOS - was just testing. Here are frameworks for smaller tests you could base one upon: https://github.com/KhronosGroup/WebGL/tree/main/sdk/tests/conformance2/rendering
Seems related to https://bugs.webkit.org/show_bug.cgi?id=237006
likely related https://bugs.webkit.org/show_bug.cgi?id=238022
Seems similar to : https://bugs.webkit.org/show_bug.cgi?id=236713
The same issue reported on Verge3D forums - https://www.soft8soft.com/topic/3d-artefacts-on-beta/ Looks like all scenes that use the render-to-texture feature affected.
We've also had reports of this issue (or a very similar one) from users of OpenLayers on Safari 15.4 where WebGL on Metal is enabled (see https://github.com/openlayers/openlayers/issues/13486). We haven't put together a minimal reproducible example, but here is a demonstration of the problem: https://deploy-preview-13490--ol-site.netlify.app/examples/webgl-layer-swipe.html On Safari 15.4 where WebGL on Metal is enabled, the map in the above example is transparent on the right half. As a workaround, we have found that creating the WebGL context with `antialias: false` avoids the issue (see https://github.com/openlayers/openlayers/pull/13492). Here is another version of the above example that sets the antialias attribute to false on the context: https://deploy-preview-13492--ol-site.netlify.app/examples/webgl-layer-swipe.html In the working example, imagery is shown on the left and a basemap is shown on the right.
It looks like the https://github.com/KhronosGroup/WebGL/blob/e45055745a7a501df29f4f35b61b221a22aa0194/sdk/tests/conformance/rendering/gl-scissor-test.html test might demonstrate the issue when `antialias: true` is set. ``` diff --git a/sdk/tests/conformance/rendering/gl-scissor-fbo-test.html b/sdk/tests/conformance/rendering/gl-scissor-fbo-test.html index cbe2b1689..85723fbf9 100644 --- a/sdk/tests/conformance/rendering/gl-scissor-fbo-test.html +++ b/sdk/tests/conformance/rendering/gl-scissor-fbo-test.html @@ -44,7 +44,7 @@ function checkCanvasRect(x, y, width, height, color, msg) { wtu.checkCanvasRect(gl, x, y, width, height, color, msg); } -var gl = wtu.create3DContext("canvas", {antialias: false}); +var gl = wtu.create3DContext("canvas", {antialias: true}); if (!gl) { testFailed("context does not exist"); } else { ``` When I create the context with `antialias: true` in the rendering test above, it passes for me in Chrome 99 and fails for me on Safari 15.4 (2 failures), both on macOS 12.3 M1.
The diff is correct, but the link above is wrong. It is the gl-scissor-fbo-test.html that can be used to demonstrate the issue: https://github.com/KhronosGroup/WebGL/blob/e45055745a7a501df29f4f35b61b221a22aa0194/sdk/tests/conformance/rendering/gl-scissor-fbo-test.html The issue we are seeing is not restricted to cases where scissor is used, and this may be a different issue altogether than the one reported here. I just found that the gl-scissor-fbo-test.html case could be used to reproduce an issue we are seeing with antialias: true on Safari 15.4 w/ Metal.
Thank you Tim Schaub for the minimal reproduction case. I wasn't able to reproduce the flickering problem with https://play.skyweaver.net , even with Safari 15.4 on an M1 MacBook Pro; maybe a workaround was put in place in the game. However - the suggested patch to gl-scissor-fbo-test.html definitely catches the bug, which is still present in both Safari 15.4 and Safari Technology Preview 141. It's fixed in top-of-tree ANGLE, which we'll try rolling into WebKit ASAP. Integrating that improvement to the test in https://github.com/KhronosGroup/WebGL/pull/3393 .
I confirmed this has been fixed by the ANGLE roll in https://bugs.webkit.org/show_bug.cgi?id=238171
Just to let everyone know, the fix for this has shipped in Safari 15.5.