Bug 235515 – Browser hangs with basic webgl usage such as showing pixi.js examples

• Component: WebGL
• Status: NEW

I had my game based on pixi.js (webgl) hang right from the start to the point it's unplayable. It was working fine on ios14. I now have ios 15.2.1 on my ipad air 2.

In an effort to reproduce the problem and find minimal reproduction cases, I tested all pixi.js examples.
When I open one of these pages, the browser hangs to the point I can't even refresh or click any example without waiting a lot. Often the browser does not even recover or the screen begins to flicker and I have to kill safari.

https://pixijs.io/examples/#/graphics/simple.js
https://pixijs.io/examples/#/graphics/advanced.js
https://pixijs.io/examples/#/graphics/dynamic.js
https://pixijs.io/examples/#/masks/graphics.js
https://pixijs.io/examples/#/events/logger.js
https://pixijs.io/examples/#/events/nested-boundary-with-projection.js
https://pixijs.io/examples/#/events/pointer-tracker.js
https://pixijs.io/examples/#/plugin-dragonbones/robot.js
https://pixijs.io/examples/#/plugin-dragonbones/eyetracking.js
https://pixijs.io/examples/#/plugin-projection/cards.js

[Kenneth Russell]

Wonder whether this is a duplicate of a previously reported bug which has been fixed on ToT. Only Apple engineers can build for iOS, so hoping they can triage.

Hey there, any update on this issue?
I just updated my device with ios 15.3 and it's still broken
Thanks

[Kyle Piddington]

Hi Florent, 

I'm not able to reproduce this issue on an iPhone 7 Plus while on iOS 15.2.1. This might be hardware / platform specific.

To help us debug, can you try going to the following setting?
Settings->Safari->Advanced->WebGL Via Metal and disable that option?

Thank you for reporting!

Hi Kyle,

thanks for your help!
Disabling "WebGL Via Metal" does indeed seems to fix the issue.
I thought I has tested that previously with 15.2.1 but I probably failed to kill safari properly.

My device is iPad Air 2 MNV22NF/A

Is there any way to detect if this option is enabled and hint users to disable it?

Thanks

[tbomb80]

I'm seeing the same issue in Safari on iPad Air 2 devices with, OS versions 15.2.1 and 15.3, model number MGL12LL/A, but this does not repro on iPhone XR, iPhone 13 or iPad Gen 6. I'm also seeing the issue fixed by disabling "Settings->Safari->Advanced->WebGL Via Metal".

My use case is slightly different, WebGL content loaded using WKWebView in an iOS/iPadOS app, and it results in an app crash in that scenario. From what I can tell, disabling the Safari setting "Settings->Safari->Advanced->WebGL Via Metal" does not impact WKWebView's behavior.

Here are some more examples that trigger this issue
https://phaser.io/examples/v3/view/actions/grid-align
https://phaser.io/examples/v3/view/actions/inc-x-layers


Would a fix for Safari also impact WKWebView?

[tbomb80]

(In reply to tbomb80 from comment #5)
> I'm seeing the same issue in Safari on iPad Air 2 devices with, OS versions
> 15.2.1 and 15.3, model number MGL12LL/A, but this does not repro on iPhone
> XR, iPhone 13 or iPad Gen 6. I'm also seeing the issue fixed by disabling
> "Settings->Safari->Advanced->WebGL Via Metal".
> 
> My use case is slightly different, WebGL content loaded using WKWebView in
> an iOS/iPadOS app, and it results in an app crash in that scenario. From
> what I can tell, disabling the Safari setting
> "Settings->Safari->Advanced->WebGL Via Metal" does not impact WKWebView's
> behavior.
> 
> Here are some more examples that trigger this issue
> https://phaser.io/examples/v3/view/actions/grid-align
> https://phaser.io/examples/v3/view/actions/inc-x-layers
> 
> 
> Would a fix for Safari also impact WKWebView?

This looks related to https://bugs.webkit.org/show_bug.cgi?id=228904

[Kyle Piddington]

Hi all,
I've noticed that PixiJS version 4 samples still run correctly with the Metal backend. I know that asking the differences between V4 and V5 is an unreasonable ask, but is it possible there's a difference in WebGL1 and 2 support?

[Radar WebKit Bug Importer]

<rdar://problem/88269340>

Hi Kyle,

I can confirm, having checked pixi's code, that lastest versions of pixi will attempt to create a webgl2 context while v4 will only create webgl context.

I've tested with my device and the first 3 samples will run on pixi v4 but not these two:
https://pixijs.io/examples-v4/#/masks/graphics.js
https://pixijs.io/examples-v4/#/plugin-projection/cards.js
(they run without WebGL Via Metal)

Also, my problematic games all use pixi v4 and therefore do not create webgl2 contexts

Hi,
the issue is still present in 15.3.1

[tbomb80]

Hello,

The issue is still present in 15.4.1.

Are there any updates available from the WebKit team on this issue?

Thanks,
Tim.

[Kyle Piddington]

Created attachment 459742 [details]
Patch

[EWS Watchlist]

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

[Kimmo Kinnunen]

Comment on attachment 459742 [details]
Patch

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

> Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:811
> +    if(mImplicitMultisampleStoreAction == MTLStoreActionDontCare)

I feel there must be a better way to select the codepath. 
like pass the context or display as parameter to the FramebufferMtl constructor..

> Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:1149
> +            colorAttachment.storeAction = getMultisampleResolveStoreAction(context);

so if I understand correctly, the issue is that Apple2 GPU family doesn't support MTLStoreActionStoreAndMultisampleResolve?
And this patch:
 1. fixes the GPU restarts on GPU family Apple2 when doing multisampled rendering with preserveDrawingBuffer == false
 2. "breaks" the GPU family Apple2 when doing multisampled rendering with preserveDrawingBuffer == true. With the caveat about "breaks" that it never worked anyway, as it would cause GPU restart 

to fix 2, we'd need additional patch 3. that implements manual resolve blit? And in this patch, we would touch these call sites to say "storeAction = MTLStoreActionStore", and then the resolve would happen in the resolve step in onFrameEnd?

[Kyle Piddington]

(In reply to Kimmo Kinnunen from comment #14)
> Comment on attachment 459742 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=459742&action=review
> 
> > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:811
> > +    if(mImplicitMultisampleStoreAction == MTLStoreActionDontCare)
> 
> I feel there must be a better way to select the codepath. 
> like pass the context or display as parameter to the FramebufferMtl
> constructor..
> 
> > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:1149
> > +            colorAttachment.storeAction = getMultisampleResolveStoreAction(context);
> 
> so if I understand correctly, the issue is that Apple2 GPU family doesn't
> support MTLStoreActionStoreAndMultisampleResolve?
> And this patch:
>  1. fixes the GPU restarts on GPU family Apple2 when doing multisampled
> rendering with preserveDrawingBuffer == false
>  2. "breaks" the GPU family Apple2 when doing multisampled rendering with
> preserveDrawingBuffer == true. With the caveat about "breaks" that it never
> worked anyway, as it would cause GPU restart 
> 
> to fix 2, we'd need additional patch 3. that implements manual resolve blit?
> And in this patch, we would touch these call sites to say "storeAction =
> MTLStoreActionStore", and then the resolve would happen in the resolve step
> in onFrameEnd?

That sounds correct to me, we'd need to add in a better resolve path for GPUFamily2.