Re: [ScriptYielding] setImmediate clamping returns.

Le 13/08/2013 03:11, Kyle Simpson a écrit :
>> Please, find a flaw. Please, make a better, more in depth analysis that shows that browsers will keep not clamping.
>> Really on this one, I really want to be wrong. I really want someone comes up with elements I haven't thought of.
> The flaw I see is that you're practicing pessimism-driven design.
:-p
I find myself realistic unfortunately. Apparently, I am not the only one 
thinking that. Unfortunately too.

> ------------------
>
> I made this analogy on the FF thread, and it was largely ignored. I'll re-try here.
>
> requestAnimationFrame() can be abused. You can put a whole bunch of code into a rAF callback that's an abuse, in that it has nothing to do with a window repaint. You can put enough slow code in that causes it to take much longer than 16ms, which means that the browser will be forced to slow down its refresh rate from ~60fps to 30 or 15 or worse.
>
> Moreover, what you abuse inside a rAF callback might not perform the same in all browsers. It might be fine in Chrome, but really painfully worse/slow in FF.
>
> At this point, we're going to be faced with the same questions we are debating theoretically here about setImmediate().
The content of the callback is irrelevant to this discussion. I want an 
answer to what happens for: function f(){ setImmediate(f) }
I demonstrated it's likely to be clamping. (on the es-discuss side, the 
discussion restarted and may yield something better we'll see).

What happens if you do function f(){ requestAnimationFrame(f) }? the 
worst thing that happens is that 60 times a second you waste the time of 
calling a function. Browsers already find acceptable to do useless work 
250 times a second, so 60 is acceptable too.

If the content of a callback is slow in one browser and fast in another, 
that's only an incentive for a browser to improve its JS perf. The 
incentive is virtuous.

But that still doesn't tell us what to do with function f(){ 
setImmediate(f) }

> If the same mindset that DID neuter setTimeout(..0) and would apparently inevitably neuter setImmediate(), the pessimism-driven design that if it can be abused, it will be abused, and if it's abused and we're the ones who get hurt, we'll be "forced" to do unspeakable evils to save our public reputation… if THAT mindset also is going to eventually be applied to rAF, then we should take rAF out right now, because it's also doomed.
But what sort of evil can browsers do? drop frames? They already do 
that. They actually happen to drop less even if rAF is misused than if 
it's not used at all. Please describe how browsers could do unspeakable 
evils to rAF, because I don't see it.

Also, remember that setTimeout(..0) got degraded because of
     function f(){ setTimeout(f, 0) }
Degradations respond to the issues they're trying to solve and rAF isn't 
subject to function f(){ requestAnimationFrame(f) }

> ---
> If you'd like me to create a demo that makes FF look really bad, and Chrome look really good, and then get it on the front page of hacker news and cause a big political uproar, and make FF "look bad", I'm sure I can. That'll force the analogy.
> ---
A bug will be filed on Firefox and the perf issue will be fixed quickly 
(which is what happens anytime someone comes up with a benchmark that 
makes some browser look very bad).
Everyone wins?

> Or, we can take a level head and say, we can't fear the idiots and let that hold back the platform. We can't ignore the abuses, but we can't live in fear of it either. We have to be balanced. We have to be creative. And most of all, we have to be willing to, sometimes, not choose the politically convenient/expedient answer.
I used to think this way... And then, I guess I spent too much time 
speaking with browser vendors :-/
Browser vendors do fear idiots, do fear abuses, do fear the press. This 
has held the platform back and until everyone (tech journalists first 
and foremost!!) both has an excellent level of JS and understands the 
impact of a bad website on the ecosystem (never?), I don't think that 
can change.
I believe I'm being realistic, not pessimistic here.

Just to clarify, I think the word "politically" is not appropriate in 
this context. We're more in a situation where we have an (complex!) 
ecosystem, actors (of different categories: users, browser vendors, web 
developers), rules, diverse interactions between the actors and each 
browser vendors actor has a strong incentive to maximize some metrics 
(market share). Decisions are made, but they are not political in the 
sense that they are not voluntary. They are natural consequences of the 
rules.
For instance, fixing this bug [1] isn't a "free will" chosen voluntary 
action. It's a consequence of not wanting to loose market share.

setImmediate (and any feature for that matter) must be thought out as 
impacting this ecosystem, but we need to make sure the ecosystem doesn't 
fire back destroying the initial intention that led to the intrusion.

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=903332

Received on Tuesday, 13 August 2013 02:04:06 UTC