Why is WebGL so slow on iOS?

I have a very simple 12 mb "game". It's just some canvas, pictures, two movements and a particle effect. Basically I'm creating animated "PowerPoint"-ish slides.

It runs perfectly on desktop and Android, but on iOS (iPhone 6) it's very laggy. After I check out every slide and go back the speed becomes a bit normal. Ironically I get the least lag from a rotating 3D model. Everything else is very laggy and slow.

If you have iOS check it out: www.roseportalgames.com/files/web/index.html

Can someone please advise?

Are there specific things I should watch out for that would affect speed on iOS but not Android/desktop?

(ps: I realize officially WebGL shouldn't be run on mobile, but it should run fine I think, it runs fine on Android. Not sure why it's so slow on iOS. There must be a way to fix it.)

 

Webassembly doesn't run on iOS and Chrome 63.0 or Safari 11.0.2, it loads the load bar but then nothing happens. No Unity logo in the center either.

 

I can reaffirm twinmatrix's finding on multiple iOS devices running iOS 11.2.5. This was building from Unity 2017.2.0f3, 2017.3.1f1, & 2018.1.0b8. The only difference is 2017.3.1f1 and above do not go to a black screen when they freeze, but freeze while the unity loading bar is still showing.

 

So far, only iOS 11.2.1 supports webgl + wasm well, other versions have all kinds of issues including the latest iOS 11.3 beta6, I found the major issues are out of memory and wrong wasm value.
PS: If iOS Safari doesn't support WASM, it uses JS mode, but as Safari(WebKit) optimization strategy, if used memory exceeds a threshold, JIT will be turned off, it means JS performance is very slow.

 

Refer to this article, maybe Apple can fix this issue before May or June?

https://www.construct.net/jp/blogs/...oke-webassembly-and-are-leaving-it-broken-898

 

I'm also struggling with WebGL performance on IOS Safari. My Webgl app basically is doing the following: Loading, compiling, loading an assetbundle, instatiating objects.
While on desktop pc's and android this is working just fine on IOS I noticed a strange behaviour: After first loading the performance is about 5fps.
When i reload the page, or when I put the Safari in the background and in the foreground again the performance is about 40fps which is perfect for this app (tested on iphone 7+8).
It would be the rescue for the project if there is a trick or workaround to persuade the safari to work directly in the fast mode.
I know that "mobile" isn't supported yet but maybe somebody has a hint or idea or similar phenomenas?

What i tried so far: As i thought of some OS-based throttling (btw power/battery settings are on "peak performance") i created a heavy cpu-load after instantiating 3D.
Interestingly on the iphone8 the fps went directly to 30. But for older devices the app was then unusable
Memory usage is ~120MB, render path: vertex, webgl type 1.0

Thanks for every kind of feedback!

 

(Unity) wasm and iOS are still broken for anything not trivial (and even then, you'll get huge graphics anomalies).

 

Is there any update on this matter? I'm still having the same issue: asm.js + Safari/Chrome + iOS = ugly performance, wasm.js + Safari/Chrome + iOS = freeze on loading screen.

 

I've had to work on other things this week, but I'm trying to determine "whose problem it is" (Unity vs Apple vs Mozilla/emscripten). I've been trying (with varying levels of success) to build with newer versions of emscripten to see if some of their latest additions resolve the issue. It's difficult though because updating too far tends to cause desyncs (for a lack of a better term) with Unity's webgl build pipeline which results in non-working builds.

Overall, I think it's still an Apple problem with a chance of being a Unity problem. The issue I'm betting is Apple caused multiple wasm bugs with their meltdown fix. They fixed the "main/big one" in 11.3, but others remain (that for [some reason] only seem to effect Unity since other wasm applications built by emscripten seem to now work on 11.3). Unfortunately for us, I'm also betting Apple is not currently aware of this and not prioritizing a fix (I bet if you ask Apple they would say "wasm works in 11.3 and later").

It could still be a Unity bug though (with perhaps how they allocate memory, I know Safari allows different limits depending on arm vs x86 https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/jit/ExecutableAllocator.cpp). The thing that gets me is other people can successfully use emscripten to make wasm applications that work perfectly fine in iOS. Perhaps those applications aren't "pushing the limits" like Unity wasm builds do and thus are not hitting the Safari bug. Hard to say...

The first step though is understanding the root cause of the bug. Not sure how to best do that other than making custom emscripten builds.

¯\_(ツ)_/¯

 

Well... my impression is that it's Apple's fault. I just tested on a Samsung Tablet (Galaxy Tab 3 Lite) from 2014 and after the GC I get almost the same performance as the 2018's iPad. Of course their performance are really hard to compare since they're both awful, but there are 4 years between them!!!!