Timeout clamp in Firefox 5
Boris Zbarsky
The caveat is that on Windows we will only sometimes be able to deliver
on this. It'll depend on what other apps the user is running or has run
in the past. Luckily for us, in many cases this will "work" due to bugs
in other applications. When it doesn't work, we'll be delivering an
average of 8ms or so, not 4ms.
Are there any objections to this plan?
For full disclosure, the two other possible courses of action are:
1) Leave the clamp at 10ms. Pros: no web compat risk. Cons: terrible
for marketing due to badly written performance tests.
2) Try to fix timers on Windows in the Firefox 5 timeframe. Pros: the
"right thing". Cons: risky changes, at what at this point is late in
the cycle, combined with lack of someone obvious to do this work.
-Boris
Jeff Muizelaar
On 21-Mar-11, at 9:39 PM, Boris Zbarsky wrote:
> I think we should drop the timeout clamp from 10ms to 4ms for
> Firefox 5.
>
> The caveat is that on Windows we will only sometimes be able to
> deliver on this. It'll depend on what other apps the user is
> running or has run in the past. Luckily for us, in many cases this
> will "work" due to bugs in other applications. When it doesn't
> work, we'll be delivering an average of 8ms or so, not 4ms.
>
> Are there any objections to this plan?
>
> For full disclosure, the two other possible courses of action are:
>
> 1) Leave the clamp at 10ms. Pros: no web compat risk. Cons:
> terrible for marketing due to badly written performance tests.
I have a natural distaste towards changing things for marketing
reasons. I feel it hurts our brand of "doing the right thing". If this
is something web authors actually want that's different, but I worry
that we're giving out worse user experience to pander to press.
Perhaps we can turn the marketing around somehow?
> 2) Try to fix timers on Windows in the Firefox 5 timeframe. Pros:
> the "right thing". Cons: risky changes, at what at this point is
> late in the cycle, combined with lack of someone obvious to do this
> work.
Some additional cons:
1) increased cpu usage causing reduced battery life for sites that are
using a lower timeout than they actually need.
2) reduced responsiveness because now a sites will use more of the
cpu. This is a bigger concern for us than other browsers because we're
the only one without content in a separate process.
What's the use case for needing a timer that runs at more than 100Hz?
-Jeff
Boris Zbarsky
>> 1) Leave the clamp at 10ms. Pros: no web compat risk. Cons: terrible
>> for marketing due to badly written performance tests.
>
> I have a natural distaste towards changing things for marketing reasons.
> I feel it hurts our brand of "doing the right thing". If this is
> something web authors actually want that's different, but I worry that
> we're giving out worse user experience to pander to press. Perhaps we
> can turn the marketing around somehow?
I should have been more clear. At some point we're going to want to
lower the clamp to 4ms in "most cases". That's what the HTML5 spec
calls for, web authors claim to prefer it, and that's what every browser
except us is shipping as of today.
So "leave the clamp at 10ms" just means "leave it for Firefox 5". It
doesn't mean leaving it there permanently.
(As an aside, I don't see any way to turn the marketing around on this;
writing bogus performance tests is a _lot_ easier than writing good
ones, so any given test someone writes for themselves will tend to be
bogus. Unless we plan to have marketing genies hovering over every web
developer's shoulder, there's not much we can do about that.)
>> 2) Try to fix timers on Windows in the Firefox 5 timeframe. Pros: the
>> "right thing". Cons: risky changes, at what at this point is late in
>> the cycle, combined with lack of someone obvious to do this work.
>
> Some additional cons:
> 1) increased cpu usage causing reduced battery life for sites that are
> using a lower timeout than they actually need.
Sure; a possible solution here is the IE9 approach: use a higher clamp
when on battery.
> 2) reduced responsiveness because now a sites will use more of the cpu.
Yep. Again, the "cons" were cons of doing it in the Firefox 5
timeframe, as opposed to Firefox 6. I feel very strongly that we need
to do this no later than Firefox 6 if we want to have any way at all of
countering IE9/Chrome marketing....
> This is a bigger concern for us than other browsers because we're the
> only one without content in a separate process.
Opera is in the same boat wrt processes; they're shipping a 4ms clamp.
> What's the use case for needing a timer that runs at more than 100Hz?
Breaking up work across the event loop without ending up with a huge
performance penalty is the only reasonable use case. If the question
is what it's actually used for out there... all sorts of crud.
-Boris