[webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Rik Cabanier]

On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> On May 7, 2014, at 3:15 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>
>
>
> On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt <oliver at apple.com> wrote:
>
>>
>> On May 7, 2014, at 2:41 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>> >
>> > When would I as a user, not want a page or web application to be as
>> fast as possible? Has a user ever complained about a desktop app that uses
>> too many of his CPU's? I think Oliver's point was that other processes
>> might fight for the same CPU resources but that is not unexpected for users.
>>
>> What happen if i go to your website while i'm doing something else in the
>> background?  What if i'm playing a game while waiting for my machine to do
>> something else? What if your page is in the background? Or my battery is
>> running low.
>>
>
> Sure. However, a page can already do this today.
> This will just give the author a way to make a semi-informed decision.
> Without this, he might just spin up too many threads and starve the rest of
> the system.
>
>
>> You need to stop thinking in terms of a user wanting only one thing to
>> happen at a time.
>>
>
> I'm not sure if I follow. How would this be any different from a regular
> desktop application?
>
>
> The argument is that this is not behaviour that users want - the fact that
> desktop applications do this is a bug in the programming model.
>
> APIs like GCD were specifically created to allow a developer to make an
> application than can automatically scale (or descale) to match the
> behaviour that is best for the user. That’s the model we want to encourage
> on the web.
>

Filip already covered this much better than I could in the webkit bug:
https://bugs.webkit.org/show_bug.cgi?id=132588

This proposal is not about inventing a thread/task scheduling mechanism;
this is just a way to make an informed guess without having to use a
polyfill,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140507/1f98d798/attachment.html>