Re: [Efficient Script Yielding] Re: [minutes] 20110706 Web Performance WG Teleconference #40

On Tue, Jul 12, 2011 at 8:47 PM, Jason Weber <jweber@microsoft.com> wrote:

>  James/Ian,****
>
> ** **
>
> Can you explain to the working group what real world scenarios lead to
> Chrome (and later HTML5) decreasing the setTimeout/setInterval frequency to
> 1ms and later clamping at 4ms? Those are the exact scenarios where
> setImmediate makes sense today.
>

The reason that nested timers are clamped at 4ms is exactly the reason why
setImmediate() does not make sense.



> ****
>
> ** **
>
> If those scenarios don’t exist we should discuss increasing the HTML5
> setTimeout/setInterval frequency to 16.7ms (visual refresh) which is the
> fastest a web application could perform work that would result in a visual
> change to the user. That would allow the web to move away from CPU
> interrupts altogether and begin to address the negative power implications
> of HTML5 on x86/x64 platforms.
>

This makes the false assumption that timers are always related to visual
effects.  Authors who are trying to schedule work tied to the visual refresh
rate should generally be using requestAnimationFrame().  If there are use
cases for scheduling work tied to visual refresh that
requestAnimationFrame() does not cover then we should consider those use
cases and see what we can come up with.

- James

> ****
>
> ** **
>
> Thanks, Jason****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* public-web-perf-request@w3.org [mailto:
> public-web-perf-request@w3.org] *On Behalf Of *James Robinson
> *Sent:* Tuesday, July 12, 2011 7:00 PM
> *To:* Sigbjørn Vik
> *Cc:* public-web-perf@w3.org
> *Subject:* Re: [Efficient Script Yielding] Re: [minutes] 20110706 Web
> Performance WG Teleconference #40****
>
> ** **
>
> On Tue, Jul 12, 2011 at 3:07 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:*
> ***
>
> On Thu, 07 Jul 2011 00:28:02 +0200, Jatinder Mann <jmann@microsoft.com>
> wrote:****
>
> Meeting Summary:****
>
>
>
> 3.      Feedback and discussion on the setImmediate specification
>
> There are a few discussions happening on the mailing list regarding
> feedback and clarifications on the current setImmediate design, including
> clamping, allowing the UA to delay the event, script based schedulers,
> frequency and power consumption benefits of this API. In this call, pros and
> cons were discussed for not clamping the setImmediate API. It was decided to
> continue the discussion on the mailing list.****
>
>
> Should we try to find use cases for the specification before we start
> discussing the details? It would seem that how we choose to implement it
> depends on what we want it to do. I have seen several calls for the use
> cases on this list, but so far no consensus.
>
> The only use case I have seen so far is this:
> 1. Allow a script to tell the browser "If there are any other scripts to be
> executed, you may do so now, but please come back to me immediately
> afterwards (faster than a clamp would do)"
> (I do not consider working around browser bugs (e.g. frozen UI) to be real
> use cases.)
>
> If this is the main use case, it would heavily influence the clamping
> discussion. setImmediate would also be identical to setTimeout, so we could
> also consider extending setTimeout with an additional parameter: boolean
> yes_I_really_mean_the_timeout_I_wrote
>
> I have also seen calls for a way to tell the browser "Please do all layout
> updates, and then come back to me". setImmediate does not (currently)
> address this use case, and the solution to this might end up looking quite
> different.
>
> In any case, I'd like to work out the use cases before going into the
> details of the solution.****
>
> ** **
>
> I agree.  We still haven't seen any concrete use cases of pages in the wild
> or of contrived, realistic test cases where setImmediate() seems to be the
> right solution.  Without a clear idea of what problem or problems we're
> trying to solve, it's impossible to come up with a good solution.****
>
> ** **
>
> - James****
>
> ** **
>
>  ****
>
>
> --
> Sigbjørn Vik
> Quality Assurance
> Opera Software****
>
>  ** **
>