4 ms·

Chrome seems to have a more full-featured shim layer for handling older graphics drivers. I have a netbook that Firefox won't even try to launch WebGL on. Chro

by wtracy 6y ago

Chrome seems to have a more full-featured shim layer for handling older graphics drivers. I have a netbook that Firefox won't even try to launch WebGL on. Chrome seems to run WebGL just fine, though shaders with more than about twelve instructions fall off a performance cliff. (Add one multiplication operation over the limit, and performance decreases twentyfold. Keep the new line, but delete any other single line of code in the shader, and performance goes back to normal.)

Uehreka 6y ago
That’s bananas. I write a lot of complex WebGL shaders, I had never heard that some devices have such a clear (and early) performance cliff.
- Kiro 6y ago
  So what is the issue in this game? I presume the banner is there for a reason. I see a lot of complaints about it and if it really was something easily fixed someone should make a PR.
- Jasper_ 6y ago
  I imagine it's doing the SwiftShader fallback, and the JIT tends to have a few specializations for "quick" shaders. Would be curious what's going on, though.
- wtracy 6y ago
  If you're curious: I don't have the machine in front of me, but it's an eee PC with I believe an Intel n550 CPU and an Intel GMA 3150 graphics chipset. I saw this behavior under a recent version of Ubuntu, probably 19.10. (The "fast" framerate was something like one frame very 1-2 seconds, which was acceptable for running an image filter. The slow framerate was one frame every 30-40 seconds, during which Chrome locked up completely.)
CraftThatBlock 6y ago
Not sure how true this is, since both Chrome and Firefox use ANGLE as their default WebGL backend (at least on Windows). https://github.com/google/angle https://github.com/google/angle
- wtracy 6y ago
  I saw this behavior under Ubuntu. Poking around the Firefox wiki, it looks like it uses it's own native backends on basically every platform except Windows. I have no idea whether any of this is relevant to the original Firefox support issue.

by wtracy 6y ago

Uehreka 6y ago

That’s bananas. I write a lot of complex WebGL shaders, I had never heard that some devices have such a clear (and early) performance cliff.

Kiro 6y ago
So what is the issue in this game? I presume the banner is there for a reason. I see a lot of complaints about it and if it really was something easily fixed someone should make a PR.
Jasper_ 6y ago
I imagine it's doing the SwiftShader fallback, and the JIT tends to have a few specializations for "quick" shaders. Would be curious what's going on, though.
wtracy 6y ago
If you're curious: I don't have the machine in front of me, but it's an eee PC with I believe an Intel n550 CPU and an Intel GMA 3150 graphics chipset. I saw this behavior under a recent version of Ubuntu, probably 19.10. (The "fast" framerate was something like one frame very 1-2 seconds, which was acceptable for running an image filter. The slow framerate was one frame every 30-40 seconds, during which Chrome locked up completely.)

CraftThatBlock 6y ago

Not sure how true this is, since both Chrome and Firefox use ANGLE as their default WebGL backend (at least on Windows). https://github.com/google/angle https://github.com/google/angle

wtracy 6y ago
I saw this behavior under Ubuntu. Poking around the Firefox wiki, it looks like it uses it's own native backends on basically every platform except Windows. I have no idea whether any of this is relevant to the original Firefox support issue.