Hey Ashley, I suspect the M133 in the chrome status page will be updated to a later release. I also put the bug link (https://issues.chromium.org/40277080) on that page.
Thanks for the feedback. Right now we're in a situation where we definitely need to remove SwiftShader WebGL support but we're evaluating other ways to support fallback based on this kind of thread. WARP is a possibility but still suffers from continuing to run JITed code in processes that are high security risk and difficult to sandbox. The "users have a poor experience" situation is more than just content running slowly. A common case where users result in software fallback is due to GPU driver crashes and hangs, to the user this is a series of flickers and hangs in the page followed by it running slowly because the whole browser switched to software rendering. We'll likely update the feature page again once David is back from holiday. Geoff On Wed, Nov 27, 2024 at 10:28 AM François Beaufort <fbeauf...@google.com> wrote: > According to https://issues.chromium.org/40277080, I believe > geoffl...@chromium.org should be able to help you. > > On Wed, Nov 27, 2024 at 4:22 PM 'Ashley Gullen' via blink-dev < > blink-dev@chromium.org> wrote: > >> Hi folks, it's been a week, is anyone from the relevant team able to >> review this and respond? >> >> Best regards >> >> Ashley >> >> On Wed, 20 Nov 2024 at 16:54, Ashley Gullen <ash...@scirra.com> wrote: >> >>> Hi Blink developers, >>> >>> I am concerned about this entry on Chrome Platform Status "Remove >>> SwiftShader fallback", currently scheduled to ship in M133: >>> https://chromestatus.com/feature/5166674414927872 >>> >>> There does not appear to be an associated bug, nor have I seen any >>> intent to deprecate associated with this on blink-dev. It appears to be an >>> unannounced unilateral decision by Google which I'm worried has the >>> potential to have a big impact on products and web content relying on >>> WebGL, like our commercial browser-based game engine Construct ( >>> www.construct.net). >>> >>> For many years now web developers have been able to assume that WebGL >>> support is ubiquitous. Numbers are hard to come by, but the best available >>> are probably from Web3DSurvey (https://web3dsurvey.com/): WebGL 1 is >>> supported on ~99.7% of devices, but ~2.7% of uses report "major performance >>> caveat", which seems likely to indicate SwiftShader. At web scale, this is >>> tens of millions of users. Worse, this survey may in fact be biased towards >>> high-end users with more modern systems that are more likely to have >>> hardware/driver support for WebGL - the real number could be larger. WebGPU >>> still has much lower support numbers so that does not look like a >>> workaround. Canvas2D is not a viable workaround for modern content, and the >>> ubiquity of WebGL has meant even tools like Construct that used to support >>> a Canvas2D fallback ultimately removed it and went all-in on WebGL. >>> >>> I suspect for years we have been able to assume that WebGL support is >>> ubiquitous in large part due to the Swiftshader fallback covering the last >>> few percent of users who don't have suitable hardware/drivers. Content that >>> works slowly is better than content that does not work at all, and I fear >>> that removal of this fallback will result in companies like us, as well as >>> other major users of WebGL (three.js, itch.io, etc.) being inundated >>> with "your content stopped working!" complaints. I also find it hard to >>> understand that "users have a poor experience" with the CPU fallback being >>> given as a justification for this, as content that does not work at all is >>> a far worse experience than having it run but slowly, and is far more >>> likely to result in customers contacting support. >>> >>> This could end up being a disaster for us. It would help ease my mind if >>> Google could: >>> >>> - Provide data about the Internet-scale usage of software fallback >>> for WebGL demonstrating that removal will have minimal impact >>> - Use some other software fallback like WARP on Windows: >>> >>> https://learn.microsoft.com/en-us/windows/win32/direct3darticles/directx-warp >>> - Provide software fallback for WebGPU so there is a possible >>> workaround with the newer API >>> - At least delay this decision until there has been time to discuss >>> with WebGL developers and determine the impact, identify workarounds, >>> implement them and roll out the changes >>> >>> It would also be useful if Google could explain the precise timeline for >>> this - it's not clear whether M133 is the beginning of a deprecation >>> period, or the point of removal. >>> >>> Best regards >>> >>> Ashley Gullen >>> Scirra Ltd >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73gJTc1ur8v-aVR3rTsOa%3DeTmDHWEpNuPAyWHQkbUPFt5w%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73gJTc1ur8v-aVR3rTsOa%3DeTmDHWEpNuPAyWHQkbUPFt5w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BPGBXuehHOnzUSpBdP6BAs7re%3D37KAo6QNzydneAE5P%2Btoqhg%40mail.gmail.com.
