[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] psa: battery api: just use all battery

Hi all -

This isn't the right place for discussion about the battery API - there are certainly valid reasons why a web app may wish to know the battery status, and those should be brought up with the Device & Sensors working group in the W3C. Their mailing list is here - http://lists.w3.org/Archives/Public/public-device-apis/

Also, Uber is not and has not to anyone's knowledge done anything with battery level. The original mention of them seems to have been due to a misreading of a comment about how people with low batteries are more likely to accept surge pricing. Uber also does not have a web app, only a native app, where battery info is generally available.

- Vlad

On Nov 2, 2016 9:17 AM, "Aleksandar Rodic" <aleksandar.xyz@gmail.com> wrote:
I understand the privacy concerns but I don't see the reasoning behind completely shutting off the API. Why not enable it through application specific permissions? That way, Uber would have to ask users to read battery state and users can politely say "no way".

There are many other privacy-sensiteive APIs like camera and microphone and the privacy problem has been solved already.

On Wed, Nov 2, 2016 at 3:26 PM Maksims Mihejevs <max@playcanvas.com> wrote:
I can clearly see very good usages of Battery API, for example in web clients of social networks, and in native apps as well (although conversation here about web).
Social network can filter content based on its nature of being heavy on battery, for example it can show less video content and minify video thumbnails to make it less likely clicked so to keep users preserving their battery for longer.
Same applies to many other content on the web, video autoplay - can be disabled if battery is below lets say 30%.
In WebGL big usage would be to go down to 30fps from 60fps, to preserve battery by reducing pressure on GPU. And even more, changing DPI on page, that slices fill rate 4 times. That way users can engage with content for much longer and without too much harm. And Battery API allows a developer to do so.
On many platforms going Fullscreen, games can show battery status, as header is hidden in fullscreen - this is good way to keep user aware of his battery.

And there is many more use cases.
I very agree with Florian on this.

On 2 November 2016 at 11:09, Florian Bösch <pyalot@gmail.com> wrote:
The opponents of this functionality argue (among other things) that it's used in a bad fashion by Uber (surge pricing more to users with low battery) and should therefore be removed.

I believe this to be a spurious argument. Is Uber misbehaving? Yes. But what does it actually say about the value of a battery API? What it says that clearly users are intimately cognizant of their battery status, and that they're willing to spend actual money to preserve it, indicating that they value their battery, and in the case of Uber, they value it so much that they're sometimes statistically significantly more willing to pay a surcharge.

This clearly demonstrates that the battery API has value to users, even when Uber is misusing it.

This value will be vacuumed up when the API is removed. At present this might seem small (it's true, it's rarely used so far), but there's no telling if the future value would be so small. Would we know the value of losing a feature that takes a long while to adopt if it was revoked after a short period of time?

If say WebGL or CSS media queries or flexbox was removed after a short period before anybody had a substantial grip on the technology on the grounds that they're flawed features, what would the value be that was lost? Well clearly we can argue with hindsight that it would be pretty large now, because the hardware accelerated web and the responsive web would barely exist. But could you make that assessment from your armchair before those points where proven?

A short while (mere months) after WebGL was introduced, Microsoft argued that "WebGL is considered harmful" and made allegations of unsuitability of it for the web, and that they would never support it [source: https://blogs.technet.microsoft.com/srd/2011/06/16/webgl-considered-harmful/]. Should WebGL just have given up and be removed then?

Who can tell the exact value of a feature to be removed for the future of the Web if you don't give it appropriate time to be explored? Well clearly in this case, the opponents of this feature make that determination for the entire web. I admire the crystal ball they seem to possess that allows them to accurately predict the future value of a feature.

On Wed, Nov 2, 2016 at 11:07 AM, Cameron Yule <cameron@cameronyule.com> wrote:
Florian, do you have a link to an announcement?

I'd potentially be okay with losing the battery API if the browser had a way to tell my application it's throttling resources for a reason. 

On Wednesday, 2 November 2016, Maksims Mihejevs <max@playcanvas.com> wrote:
Apple always needs to be different and just worse.
Tons of bugs and issues because of their GPU specifics and now they removing API's..

On 2 November 2016 at 01:56, Florian Bösch <pyalot@gmail.com> wrote:
this just in. for the first time mobile (battery driven) browsing overtook power outlet driven browsing. so lets give those meddlesome mobiles a run for their battery life as the most emerging device category... because reasons.

On Wednesday, 2 November 2016, Florian Bösch <pyalot@gmail.com> wrote:
mozilla and apple are removing the battery api that would let performance intensive apps, such as webgl ones, choose a less or more battery intensive mode of operation automatically. they reason "os'es are now good at that stuff."

so just crank your rendering code to max and kill that battery. who needs battery life anyway. its no longer like you could tell you where killing the battery, so dont worry.