- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Tue, 12 Jul 2011 12:07:47 +0200
- To: public-web-perf@w3.org
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. -- Sigbjørn Vik Quality Assurance Opera Software
Received on Tuesday, 12 July 2011 10:08:27 UTC