[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Disable software rendering
On Mon, Jun 20, 2011 at 1:44 AM, Mark Callow <email@example.com
> That's a nearly unbelievable example. It is fairly easy to use NPOT images as texture sources even without hardware support. Pad it to a power-of-two and fudge the app-provided texture coordinates - admittedly not as easy with fragment shaders as it was with fixed-function texture transform matrices.
It's anything but easy. You can't simply "fudge" coordinates; that gets edge conditions wrong.
On Mon, Jun 20, 2011 at 2:01 AM, stephen white <firstname.lastname@example.org>
We had the same problem with browser features, and "feature sniffing" won out over browser detection. Building up tables of cards seems like an elaborate version of browser detection, so a suite of feature sniffs could be a good way to approach this problem?
It's not quite analogous. Feature detection is clear-cut: either a feature exists or not. Running benchmarks to detect GPU support is much fuzzier. There are many cases where that's the best you can do, unfortunately, since "support" for a feature on GPUs is on an analog performance scale, not a boolean.
Sorry to keep pushing this point, but I'm experiencing life as a normal user with an enabled WebGL browser, and it's not too good... I should be able to open many tabs, and those tabs will only activate when being viewed. This is the current behaviour with Flash, and that works well.
To go back to your original question, if software fallbacks are causing the browser to hang, then the solution, if at all possible, is to make that not possible in general, not to whack-a-mole the individual things that might cause it. You can sometimes freeze OpenGL pretty badly with shaders, even when software rendering isn't involved.
Also, I'd expect requestAnimationFrame to also only report frames when a tab is visible, so animations on backgrounded tabs stop. I havn't checked if it does, but that seems basic.