On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:
In short, our architecture makes me
Hi Peter,
On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote:
On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote:
As another drastic anecdotal step, I've turned off javascript on
Safari (my main browser) and turn to other browsers when I find a site
that requires javascript. If I
Hi Darin,
On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
(I don't understand your
Hi Peter,
On Oct 3, 2008, at 12:21 PM, Rob Burns wrote:
On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote:
On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote:
As another drastic anecdotal step, I've turned off javascript on
Safari (my main browser) and turn to other browsers
HI Darin,
On Oct 3, 2008, at 1:22 PM, Darin Fisher wrote:
On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns [EMAIL PROTECTED] wrote:
Hi Darin,
On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Oct 2, 2008, at 10:09 PM,
On Oct 3, 2008, at 3:10 AM, Rob Burns wrote:
Hi Darin,
On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL
HI Maciej,
On Oct 3, 2008, at 3:16 PM, Maciej Stachowiak wrote:
On Oct 3, 2008, at 3:10 AM, Rob Burns wrote:
Hi Darin,
On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Oct 2, 2008, at 10:09 PM, Darin Fisher
On 03/10/2008, at 14:16, Maciej Stachowiak wrote:
[...] Other sites update their title on a timer in a way that is
useful for a background tab. For example, GMail updates the unread
count, which is quite useful on a background tab label. [...]
Maybe the new Timer API should be extended
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Are you planning to test a specific alternate interval?
I believe Mike is raising the Chromium clamp to 4 ms.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Oct 2, 2008, at 6:01 AM, Linus Upson wrote:
My impression from your remarks was that you thought 1ms is working
fine
1ms is definitely not working fine for me. I've started reading the
Washington Post since NYT makes my fan whir.
As another drastic anecdotal step, I've turned off
On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote:
As another drastic anecdotal step, I've turned off javascript on
Safari (my main browser) and turn to other browsers when I find a site
that requires javascript. If I don't do that, I find my Macbook Air
battery eaten away in
On Wed, Oct 1, 2008 at 5:26 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 1, 2008, at 5:03 PM, Darin Fisher wrote:
On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 1, 2008, at 1:24 AM, David Hyatt wrote:
On Oct 1, 2008, at 2:52 AM, Darin Fisher
On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:
I am indeed interested in passive feedback from users and web
developers. But I'm also interested in the anonymous, opt-in
aggregate data collection that we can perform ourselves (as Linus
mentioned). The challenge is to find a way to
On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:
In short, our architecture makes me more willing to take risks with
setTimeout clamping than I would be otherwise.
I think you've already seen this, but in case you haven't - here is the bug
where I've been tracking this. Every report I've seen related to minimum
timers is referenced in here.
http://code.google.com/p/chromium/issues/detail?id=792
I think the evidence is pretty compelling that 10ms and 1ms
On Tue, Sep 30, 2008 at 11:55 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Sep 30, 2008, at 10:36 PM, Darin Fisher wrote:
On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
...
2) Consider making WebKit's default minimum timer limit lower - something
like
We can use the histogram facility in chrome to collect data from a dev
channel release. It should only take a few weeks to get good data.
What exactly do we want to measure to settle on a value?
Linus
On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 1, 2008,
On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 1, 2008, at 1:24 AM, David Hyatt wrote:
On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote:
I can appreciate that you aren't interested in revisiting this problem
after having resolved it finally by adding the
My impression from your remarks was that you thought 1ms is working fine
1ms is definitely not working fine for me. I've started reading the
Washington Post since NYT makes my fan whir.
Linus
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Thanks for the concrete examples, Dave! I tested all 3 of these, and
haven't yet found any problems. But I don't have specific URLs. I also
looked through the webkit bugs database as much as I could, and could not
locate them.
BTW - if the primary concern is not spinning the CPU, we could just
When I use setTimeouts, often the event has already occurred. So rather than
clamping, I'd suggest increasing the timeout up to 10ms rather than clamping it
at the start. Thus, if I specify 0, an immediate check would occur, then move
it up each time, maybe 1, 5, 10 would be optimum.
On
Sep 30, 2008, в 6:37 PM, Mike Belshe написал(а):
Thanks for the concrete examples, Dave! I tested all 3 of these,
and haven't yet found any problems. But I don't have specific
URLs. I also looked through the webkit bugs database as much as I
could, and could not locate them.
One
Thanks - I did see that bug. Intentionally spinning the CPU vis
setTimeout(,0) is not a problem if it is what the application intended. In
the bug you mention, it mentions mapquest as a potential site with this
issue. But I can't reproduce that, and there are no specific URLs.
Mike
2008/9/30
Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а):
Thanks - I did see that bug. Intentionally spinning the CPU vis
setTimeout(,0) is not a problem if it is what the application
intended.
I don't quite agree - even though this may have been the intention,
the application developer will
I think we agree on this point - its a matter of what did the website author
intend. I believe there are legitimate cases to ask for setTimeout(1).
With a pure clamp based approach, this feature is not available today. On
the other hand, if the website author accidentally uses setTimeout(1),
Agreeing with Alexey's points here and adding one more...
On Sep 30, 2008, at 9:32 AM, Alexey Proskuryakov wrote:
Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а):
Thanks - I did see that bug. Intentionally spinning the CPU vis
setTimeout(,0) is not a problem if it is what the application
Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а):
As for keeping the fan off - if we could keep the CPU idle a 3ms
minimum timeout loop does that resolve your concern?
Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur
non-trivial processor usage.
- WBR, Alexey
2008/9/30 Mike Belshe [EMAIL PROTECTED]
As for keeping the fan off - if we could keep the CPU idle a 3ms minimum
timeout loop does that resolve your concern?
Followup to my earlier post, based on this.
I realize that one reason why we (Chromium folks) have not been as concerned
about CPU
On Sep 30, 2008, at 9:37 AM, Mike Belshe wrote:
Thanks for the concrete examples, Dave! I tested all 3 of these,
and haven't yet found any problems. But I don't have specific
URLs. I also looked through the webkit bugs database as much as I
could, and could not locate them.
When
BTW - if the primary concern is not spinning the CPU, we could just drop
the throttle down to 2 or 3ms, and the CPU will be largely idle on most
machines. In a few years, with faster processors, we'll be able to drop to
1ms and still have largely idle CPU.
Would 3ms be viable in your
Hi Peter,
On Sep 30, 2008, at 8:42 PM, Peter Kasting wrote:
2008/9/30 Mike Belshe [EMAIL PROTECTED]
As for keeping the fan off - if we could keep the CPU idle a 3ms
minimum timeout loop does that resolve your concern?
Followup to my earlier post, based on this.
I realize that one reason
Or there is option 3:
3) Restore the clamp for setTimeout and setInterval to 10ms for
compatibility, and add a new setHighResTimer API that does not have
any lower bound.
I'd like to tweak this suggestion a bit:
Let's make this new timer API object-oriented, so it can be both less
: Tuesday, September 30, 2008 3:58 PM
To: Maciej Stachowiak
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] setTimeout as browser speed throttle
Or there is option 3:
3) Restore the clamp for setTimeout and setInterval to 10ms for
compatibility, and add a new setHighResTimer API that does
On Tue, Sep 30, 2008 at 12:17 PM, Rob Burns [EMAIL PROTECTED] wrote:
The problem is not only confined to single processor systems. As others
have mentioned the bigger problem is the waste of resources. The length of
the timeout is not the full piece of the puzzle. There's also problems with
On Tue, Sep 30, 2008 at 1:35 PM, Brady Eidson [EMAIL PROTECTED] wrote:
If we add a new well specified API that all browser vendors agree on,
everybody wins.
No; everybody who's willing and able to change wins.
Everyone else wins or loses depending on whether the new behavior is better
or
On Tue, Sep 30, 2008 at 2:50 PM, David Hyatt [EMAIL PROTECTED] wrote:
Note that these problems in Safari came from having no clamp at all. Even
Chrome has a 1ms clamp.
Right. We weren't proposing making setTimeout() unclamped; just lowering
the clamp. (And I'm sorry for using the word
Subjective note:
I'm much more worried about sites spinning the CPU accidentally (e.g. they
used setTimeout(0) somewhere by accident) than I am about frame rates on
games. Using the clock as your frame rate is super buggy, and sites need to
know better. It won't work now and it won't work going
On Sep 30, 2008, at 10:42 AM, Peter Kasting wrote:
2008/9/30 Mike Belshe [EMAIL PROTECTED]
As for keeping the fan off - if we could keep the CPU idle a 3ms
minimum timeout loop does that resolve your concern?
Followup to my earlier post, based on this.
I realize that one reason why we
On Sep 30, 2008, at 5:13 PM, Peter Kasting wrote:
On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Can you cite some of the existing sites that would benefit? That
would help others confirm the benefit and also estimate likelihood
of said sites adopting a new
On Sep 30, 2008, at 5:15 PM, Mike Belshe wrote:
On Tue, Sep 30, 2008 at 3:45 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Sep 30, 2008, at 3:06 PM, Mike Belshe wrote:
Subjective note:
I'm much more worried about sites spinning the CPU accidentally
(e.g. they used setTimeout(0)
On Sep 30, 2008, at 6:37 PM, Peter Kasting wrote:
On Tue, Sep 30, 2008 at 5:31 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
It seems to these are demo pages, tutorials, or descriptions of
techniques. Clearly tutorials and demos can adapt to a new API, and
improving their current form is
On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I agree with you that web content authors should have a way to get called
back ASAP. It seems like we have three different proposals identified that
most have agreed are worth pursuing:
1) Design an improved timer
We encountered 100% CPU spins on amazon.com, orbitz.com, mapquest.com,
among others (looking through Radar histories). This was pre-clamp.
Web sites make this mistake because they don't know any better, and it
works fine in IE. It is a mistake these sites will continue to make,
and
43 matches
Mail list logo
