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

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