101–107 of 107 posts
Not useful, all it does is lag the page and increase the cpu usage to 40% when you have hardware acceleration turned off.
I work on WebGL in Chrome and I am curious why you have hardware acceleration turned off.
Alt title: how we made yet another population density map, but this time using all of your CPU.
You'll actually find that the majority of the work for drawing this is happening on the GPU. I didn't even come close to maxing out my CPU with a stable 144fps.
Earlier quoted context omitted.
I am curious, why do you have hardware acceleration turned off? To answer your question, the failIfMajorPerformanceCaveat flag allows sites to turn off their hardware accelerated features when hardware acceleration is off.
Thanks to the globe rendering in glorious 2fps, I've just learned that apparently I don't have HW acceleration because I'm using chromium on linux.
Earlier quoted context omitted.
I work on WebGL in Chrome and I am curious why you have hardware acceleration turned off.
When activated after a while a few tabs would change their background (sometimes the entire page) to show the content of other tabs.
Earlier quoted context omitted.
I thought it was a joke too. What an awful flag all around: * Woefully ambiguous and underspecified - what is "major"? A 12 FPS drop compared to desktop? Below 30 FPS? Frame jitter outside a certain standard deviation? It will depend on the app (fast-paced frame-perfect game vs. "well I just want the animation to be smooth" necessarily have different requirements for performance), but this flag leaves it up to the br…
I can answer this. Sorry in advance for the novel. I hate the name too, but the flag was a necessary compromise to get past an impasse. The problem at the time was that fullscreen WebGL in Firefox was an absolutely terrible experience on some machines, because they did a readback of the full framebuffer from the GPU to the CPU every frame. This didn't just make that tab slow, or even just the whole browser. It actual…
As a firefox user I appreciate that we were considered. Although maybe I've got a new bone to pick with Mozilla now, since not exposing hardware/software rendering mode or readback y/n is a weird hill to die on when things like canvas font rendering fingerprinting are much more reliable and precise (if their refusal was on privacy grounds).
With the history in mind, an ideal flag to me would have been more like an enum of "minimumRequiredGLExperience" valued like ["any", , "parity"] where apps have a middle ground to say "even if we have SW rendering, maybe we'll still want GL if the browser ranks itself above the threshold value (which would be computed ahead of time and have a standard-ish definition, kind of like the scores on userbenchmark). While still somewhat nebulous, it would allow fine-tuning the experience for known target platforms.
I definitely understand the limited window of opportunity though, and rolling an entire feature like that above would be a big project so I can't fault anyone for going with the compromise. I just wish the name had been different or the documentation more clear - even the Khronos docs are wishy washy on whether SW rendering will for sure cause a failure, or if there's some implementation defined benchmark already that it boils down to. Which I realize is also something that would require work from the Mozilla side too, that they may not be willing to document for the same logic as not wanting to expose whether readback is happening in the first place!
Anyway, thanks again for responding, and I apologise for being a little abrasive in my first post.