[whatwg] suggestion for HTML5 spec

[Dirk Pranke]

On Tue, Aug 3, 2010 at 3:22 PM, Chris Marrin <cmarrin at apple.com> wrote:
>
> On Aug 2, 2010, at 7:20 PM, Dirk Pranke wrote:
>
>> On Mon, Aug 2, 2010 at 7:09 PM, Ian Hickson <ian at hixie.ch> wrote:
>>> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>>>> On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>>> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>>>>>>>
>>>>>>> Why would a user ever want anyone to disable their GPU acceleration?
>>>>>>
>>>>>> I believe I've heard people say that they might sometimes want this for
>>>>>> power management, i.e. performing the same computation on the GPU might
>>>>>> take more power than performing it more slowly on the CPU. I imagine
>>>>>> this would depend on the specific configuration and computations
>>>>>> involved, though.
>>>>>
>>>>> This seems like a matter for the user, not the Web page, though.
>>>>
>>>> Ah, I knew you were going to say this. I agree, but I can also imagine
>>>> that the way the user selects this is by choosing one of two different
>>>> resources from a page, just like we do today for videos of different
>>>> bandwidths.
>>>
>>> It seems better to have a way for the user agent to automaically negotiate
>>> the right bandwidth usage based on user preference, too.
>>>
>>> Any setting like this that we offer authors _will_ be misused, possibly as
>>> often as used correctly. Unless there's a really compelling reason to have
>>> it, it seems better to let the user be in control.
>>
>> If users can choose between two links on a page labelled "high FPS -
>> will destroy your battery" and "low FPS", they are in control, in a
>> way that is easily understood by the user and allows them to make the
>> choice at the point in time that it matters. Compare this with
>> changing the streaming settings on QT Player or Windows Media Player,
>> or even toggling the "use the video card" button on your laptop (and
>> hoping that the content is smart enough to degrade gracefully instead
>> of choking).
>
> But an author can't make that claim if it involves forcing the GPU on or off. If we were to do this, I'm sure there would be implementations where the exact opposite of the author's intent would be the result. Saying something like "turn off the GPU" can result in more or less battery usage, depending on the hardware, software and content. Preserving battery life should be the job of the system (possibly with "I care more about battery life than quality" input from the User Agent).

I think you're probably right that different systems can have
different performance profiles and you can't design a "one size
fits all" solution here. Perhaps instead of "enable GPU / disable GPU"
you need "high complexity / low complexity" as a hint to the user agent.

>
>>
>> We've seen this exact same argument play out over the last fifteen
>> years in video on the web. The technology for detecting and adjusting
>> bandwidth dynamically has been around forever (actually implemented,
>> even), and yet for every one multi-bitrate stream available on the
>> web, I imagine there are very many more that are single-bitrate. A big
>> part of the reason for this is because doing it this way is (in my
>> opinion) a better user experience.
>
> Sure, you might be able to say that a lower bitrate video will use less power than a higher bitrate one. So the author might want to provide two videos. But leave it up to the system to decide what hardware to use to play them.

Of course, you can also imagine a lower bitrate stream using more
power than a higher bitrate run (VP8 may be more efficient than MPEG-2,
but can't be decoded in hardware and hence is far more expensive).

Perhaps all this illustrates is that the problem is far from simple and
so no simple API is likely to be that helpful. I'm not sure ...

-- Dirk