Bug 233817

This issue isn't a WebKit bug technically, although certain updates to WebKit would dramatically improve the situation. Basis Universal ETC1S is a transmission format, and must be transcoded to something GPU-compatible on the client. In this case three.js detects that the device doesn't support ETC2 (has alpha) and so it transcodes to ETC1 (no alpha). ETC1/2 are more efficient and direct as a transcode target for ETC1S than alternatives, but lack of alpha is obviously a problem in this case. On the three.js side we should probably choose DXT as the transcode target instead, or decode to uncompressed RGBA. That said – it would be really excellent to see Safari support the better GPU compressed texture formats that the M1 chip is capable of using! Some references: - https://github.com/KhronosGroup/3D-Formats-Guidelines/issues/17 - https://github.com/KhronosGroup/3D-Formats-Guidelines/blob/main/KTXDeveloperGuideWebGL.md#platform-support-table

Can you please

(oops, didn't mean to publish that incomplete comment) Could you please explain what compressed texture formats seem to be missing support in Safari? To the best of my recollection, during the ANGLE port and WebGL 2.0 upgrade, we exposed all texture formats. On what hardware is this happening? What is the destination compressed texture format used during transcoding, and what's the desired destination format? On macOS 11.6.1 (I haven't taken the macOS 12 upgrade yet), Chrome, Safari, and Safari Technology Preview render: https://glitch.com/edit/#!/sponge-lemon-vulture identically. There's no issue with the transparency of the hexagonal geometry.

Also: tested on dual-GPU 2017 MacBook Pro, dual Intel HD 630 / AMD Radeon Pro 560 GPUs.

Testing on: - Safari and Safari Technical Preview - macOS Monterey 12.0.1 - Apple M1 Pro chip If you visit this demo and set a breakpoint on line 70 (`animate()`) then run ... ``` console.log( loader.workerConfig ); ``` ... I see the following: ``` astcSupported: false bptcSupported: false dxtSupported: true etc1Supported: true etc2Supported: false pvrtcSupported: false ``` So I only seem to have a choice of ETC1 and DXT on this device. In Firefox and Chrome on the same device (without flags), only DXT is supported. Technically that leads to a better result here, because it forces three.js to choose DXT instead of ETC1 as the transcode target. Full list of extensions on this device, from the WebGL 2 tab on webglreport.com: ``` OES_texture_float_linear EXT_texture_filter_anisotropic WEBGL_compressed_texture_etc1 WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_lose_context WEBGL_debug_shaders WEBGL_debug_renderer_info EXT_color_buffer_float EXT_color_buffer_half_float EXT_float_blend KHR_parallel_shader_compile WEBGL_multi_draw ```

More specifically: Safari Technical Preview, Release 135 (Safari 15.4, WebKit 17613.1.7.3).

Kyle or Kimmo, do either of you have this hardware and can you figure out why ANGLE isn't advertising the GL_ANGLE_compressed_texture_etc extension?

Good news - after discussion on Slack with Alexey Knyazev (who wrote this portion of the code) and Kyle, it seems clear that the coming ANGLE roll in Bug 220896 will fix this. This is working correctly in Chromium on top of ANGLE's Metal backend. Blocking on the other bug.

Chrome with ANGLE/Metal enabled via flags does support all compressed texture formats on M1 (confirmed by webglreport.com): EXT_texture_compression_bptc EXT_texture_compression_rgtc WEBGL_compressed_texture_astc WEBGL_compressed_texture_etc WEBGL_compressed_texture_etc1 WEBGL_compressed_texture_pvrtc WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb

That's great news, thank you!

<rdar://problem/86324039>

Considering this a dupe of Bug 220896. Should be fixed in the next Safari release that contains that roll. Please test on Safari Technology Preview on an ongoing basis and reopen this bug if it doesn't appear fixed in the next couple of weeks. *** This bug has been marked as a duplicate of bug 220896 ***