Failing seemed reasonable to me, because my context around software fallback translates to “1 or 2 fps if you are lucky”.
Maybe you have a different context.
Maybe you have a different context.
If the GPU gives you some nice fancy shading, but your game works fine without it, then GGP's suggestion to "just make it fail" is of course silly.
Slight tangent: I think a lot of "tech hot takes" (and snarky SO comments) come from a lack of imagination outside our own experience. It's easy to forget that there is often a huge diversity of applications/use-cases for the languages/libraries/etc that we use.
Not really, that's actually the point being made: if you try to use the GPU with your fancy shaders, you'd rather have it fail noisily so that you can explicitly fallback to the CPU implementation without your fancy shaders, than the library silently falling back to rendering everything (including your expensive shaders) on the CPU.
I just tried a WebGL demo, and got wildly different results depending on the browser, and which GPU is active at the time the demo started. Results varied between:
- Smooth and good looking
- Good looking but <1fps. Turning off GPU features would have been the better thing to do.
- Noisy, corrupt-looking pixels over half the image because calculations were producing incorrect numerical results; it looked like overflow or something.
At least it's possible to detect a low frame rate and, eventually, compensate by reducing features and/or resolution. But that's still annoyingly slow (it will take a few seconds to detect).
Bad calculations are a bigger problem, as it's hard to anticipate what kind of bad to look for and how to detect it.
That's not a problem with the API, that's a problem with one or more of your browsers.
Bench-marking your code during init to choose the best algorithm is a very sane thing to do if you know your users' machines/browsers may have different capabilities. We're talking about extra fractions of a second of load time. The alternative is to expose a bunch of details about what's underneath the browser, which would probably not fit with the goals of the web - it being a sort of abstraction layer over all the operating systems and devices.
It's much more of a pain when calculations come out wrong though. It's hard to anticipate all the ways that might happen, check for them, and then find workarounds when you don't have the hardware where they go wrong.
As noted in this comment https://news.ycombinator.com/item?id=24026914 some of these problems appear to be browser-independent.
Bad calculations can ruin a game, not just due to visual glitches, but by revealing things that should be hidden, for example seeing through holes in walls caused by glitches.
Arguably I prefer to have the option to use software that underperforms than to not be able use it all all, specially if performance is not that critical.
Moreover, it's not up to you to decide what's acceptable or not to a 3rd party, specially if your claim is being made to justify choosing between being able to use something that performs below par or not be able to use it at all.
Shoot, Blender still supports users without accelerated graphics. (Or did five years ago, things may have changed.)
1. Detect GPU acceleration
2. With acceleration, enable fancy bells-and-whistles, with animations and effects
3. Without acceleration, fall back to good-old-fashioned mode, with flat HTML
A lot of this depends on what YOUR software does. Is it speeding up a spreadsheet (which will probably work fine in CPU)? Is it adding fancier shaders to a video game?
Explicit beats implicit. The library should support CPU and GPU, without a doubt, but the user of the library should make the decision of what to do if GPU isn't found.
If you're writing a spreadsheet, use a fallback to CPU. If you're writing a glitzy animation, turn it off.
e.g. here's xonotic running on it on my laptop in full hd (i7-8750H): https://streamable.com/luxfv1
if I downgrade to 720p it's definitely playable.