Hi Peter,
On Oct 3, 2008, at 4:08 PM, Peter Speck wrote:
> 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 backgrou
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
h
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 extend
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 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 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 P
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 wh
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, Darin Fisher wrote:
>>
>> On Thu, Oct 2, 2008 at
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 you
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
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 architect
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.
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. This is a good thing I think
>> because we ha
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
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
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 awa
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 of
> 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
htt
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 wrote:
I can appreciate that you aren't interested in revisiting this
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 add
[once again, I sent this with the wrong origin email.]
On Wed, Oct 1, 2008 at 10:02 AM, Linus Upson <[EMAIL PROTECTED]> wrote:
> 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
On Tue, 2008-09-30 at 10:47 -0700, Peter Kasting wrote:
> Your comment in that bug was that it was 3.7% of CPU on your machine.
> 3.7% for "as fast as possible" doesn't seem like a huge burden. That
> suggests authors could write tight loops at 3ms delays and still only
> burn 10% of the CPU. I
I think we should be shooting for a target clamp value of 3-5ms.
dave
On Oct 1, 2008, at 12:02 PM, Linus Upson wrote:
> 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
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 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 clamp. I
believe you when you say you had compelling evidence too.
We
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 clamp. I
> believe you when you say you had compelling evidence too.
>
We are interested in revisiting the problem or we
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 - som
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 >1m
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 3ms-5ms. I don't know what we would do to verify that
this is "safe enough" or
Thanks everyone for the feedback and ideas. Sounds like we're converging.
Maciej - I'll volunteer to do the work in the webkit tree to reduce the
existing timer and testing that is deemed necessary (actually, I think this
is mostly a testing task; the code change is trivial). I think the test I
s
>
> 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 3ms-5ms. I don't know what we would do to verify that this is "safe
>> enough" or who would do the work. Maybe Hyatt?
>>
>
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 ti
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 i
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 not much of a benefit. How about real existing sit
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 b
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) som
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 b
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) somewhere by accident) than I am about fram
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 better API for greater benefit.
>
Sure.
http://ajaxi
On Sep 30, 2008, at 3:30 PM, Peter Kasting wrote:
On Tue, Sep 30, 2008 at 3:08 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
That seems like incorrect reasoning to me. unclamped setTimeout(0)
does not break processing of user events in a single-process browser
(I tested). But it will eq
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) somewhere by accident) than I am about
> frame rates on games. Using the clock as your frame rate is super
> buggy, and sit
On Tue, Sep 30, 2008 at 3:08 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> That seems like incorrect reasoning to me. unclamped setTimeout(0) does not
> break processing of user events in a single-process browser (I tested). But
> it will equally drain your laptop battery and produce a great
On Sep 30, 2008, at 12:58 PM, Geoffrey Garen wrote:
>> 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
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 (C
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 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 "
I'm really curious what other vendor positions are on the issue of
clamping setTimeout (e.g., Mozilla, Opera, Microsoft, etc.).
dave
([EMAIL PROTECTED])
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.c
Note that these problems in Safari came from having no clamp at all.
Even Chrome has a 1ms clamp.
I think a lowered clamp is a good idea though. I originally wanted to
change the clamp to 5ms back when I implemented the code to keep one
shots unclamped, but got talked out of it by people w
On Sep 30, 2008, at 1:41 PM, Peter Kasting wrote:
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
This debate is not new. We tried this in WebKit, when we first
released Safari.
We repeatedly encountered pages that behaved well in other browsers
and did not behave well in Safari, and the root problem was that they
had an effective minimum timer value.
It's arrogant to say that it's a we
On Sep 30, 2008, at 3:41 PM, Peter Kasting wrote:
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
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 Sep 30, 2008, at 1:19 PM, Peter Kasting wrote:
> FWIW, I'm in favor of an additional API alongside this one if it
> enables fully-uncapped timers and higher resolution than 1 ms -- but
> I don't think that changes the argument for also lowering the cap on
> setTimeout().
I think it 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 wit
: 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 setHighResTi
> 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
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
>
>
> 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
We do this now. We detect repeated setTimeouts and ratchet up to 10ms
only after a repeated firing situation has been detected.
On Sep 30, 2008, at 9:48 AM, Dave Cronk wrote:
> When I use setTimeouts, often the event has already occurred. So
> rather than clamping, I'd suggest increasing th
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.
>
Whe
2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>
> 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
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
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 Proskury
Sigh... re-sending since I used the wrong email address the first time.
PK
On Tue, Sep 30, 2008 at 10:25 AM, Peter Kasting <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 8:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
>> 1) Animations that run faster than intended by the author (it'
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 applicati
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), the
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 wil
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 Al
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.
On
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 Mond
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 d
Hi, Maciej,
Thanks for the response.
Comments below
On Mon, Sep 29, 2008 at 8:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Sep 29, 2008, at 7:26 PM, Mike Belshe wrote:
>
> Hi,
> One of the differences between Chrome and Safari is that Chrome sets the
> setTimeout clamp to 1ms as op
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 Chrom
On Sep 29, 2008, at 7:26 PM, Mike Belshe wrote:
Hi,
One of the differences between Chrome and Safari is that Chrome sets
the setTimeout clamp to 1ms as opposed to 10ms. This means that if
the application writer requests a timer of less than 10ms, Chrome
will allow it, whereas Safari wil
Hi,
One of the differences between Chrome and Safari is that Chrome sets the
setTimeout clamp to 1ms as opposed to 10ms. This means that if the
application writer requests a timer of less than 10ms, Chrome will allow it,
whereas Safari will clamp the minimum timeout to 10ms. The reason we did
thi
75 matches
Mail list logo
