EXRLoader: Throws error in r136 on iOS below 15.1

[inear]

When loading a exr texture on iOS 14 or below the device throw a runtime error and prevent the texture from being loaded.

The line that triggers the error: https://github.com/mrdoob/three.js/blob/master/examples/jsm/loaders/EXRLoader.js#L2165 (if using DWA compression the error is also triggered during decoding pre r136) The change was added in this commit: ab528ac

Steps to reproduce the behavior:

1. Load exr texture with any compression type
2. Build to device/webview or run in mobile Safari running iOS 14.x
3. See the following error: TypeError: t.getBigInt64 is not a function. (In 't.getBigInt64(e.value,!0)', 't.getBigInt64' is undefined)

Expected behavior
The loader should detect or workaround the missing support.

The current workaround is to downgrade to version 135 and use a different compression than DWAA or DWAB.

Platform:

• Device: Mobile
• OS: iOS
• Browser: Safari, WebView
• Three.js version: r136

[sciecode]

After a quick scout, it appears pre-Safari 14 fails to implement getter DataView.getBigInt64. It is possible to revert one recent change that relies internally on this method. However DWAA and/or DWAB make heavy use of 64bit precision and probably won't be easily addressed without proper getter functionalities.

I'll post a workaround patch removing the requirement during offset table traslations, but I'm afraid DWA compresion will remain unsupported on Safari, for the time being.

---

FYI: This would only return mobile Safari behavior to what we had pre-r136, I'm fairly certain DWA support was already compromised due to this lack of support.

[inear]

Makes total sense! Thanks for looking into it so quickly!

[sciecode]

It appears we are able to create and operate on BigInt64 on Safari, we just can't use DataView.getBigInt64 so I might be able to just swap execution to a custom 64b sampling when the method is not available, so everything can work properly. Posting PR asap.