[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] option for suggesting "low power" mode at context creation
Some ways to support low vs. high power cannot be switched after context creation (multiple gpus, multiple contexts). As mentioned earlier in this thread, a high power default is preferable as this is the current behavior. Switching to a low power default would break existing webgl applications that would have to be modified, and it would introduce performance regressions.
On Thu, Sep 27, 2012 at 9:01 PM, Colin Mackenzie <email@example.com> wrote:
I think the flag is a good idea in general, but I have a thought that I haven't seen anyone else voice yet. Could the browser not send the "use least power" flag by default?
On Thu, Sep 27, 2012 at 2:32 PM, Florian Bösch <firstname.lastname@example.org>
But the basic hint of either "use least power" or "use best performance" is a significant piece of information that neither the GPU, nor driver, nor the OS nor the browser can deduce.
Then, it becomes the JS developer's job to explicitly send a "use high power" flag if they are sure they want it. Having "low power" be the default would help the WebGL-enabled Internet to be mobile-friendly out of the box, and I believe it would show a lot of developers who might instinctively reach for performance that their apps can actually run without being a battery drain.
Put another way, I think it would be easier for a developer to design a mobile-friendly app if it's mobile-friendly by default, and that the same developer might think twice about consuming high power if they are made explicitly aware that they will be doing so by having to set "use best performance" flags.
Another thought is that if low power is the default, then should the browser be smart enough to switch to high power automatically in extreme circumstances: for instance, when framerate is excessively low as measured in requestAnimationFrame? And just for the record, if the browser is made to calculate framerate for this purpose, I think the result of that calculation should be exposed to JS so that the developer doesn't have to double the FPS-tracking effort. (Or is it already?)