- From: Ross McIlroy <rmcilroy@google.com>
- Date: Wed, 24 Jun 2015 16:50:41 +0100
- To: Hiroshi Kawada <kawada.hirosi@gmail.com>
- Cc: Todd Reifsteck <toddreif@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>, Ilya Grigorik <igrigorik@google.com>
- Message-ID: <CAP-rjT48LPqfuYsD0OiLunDV3tLQcx-amsmi0znXU6f6rZUOiA@mail.gmail.com>
We have been working on a proposal spec for a new API which we are calling requestIdleCallback (the name is totally up for debate, we would be fine with calling it setIdle or requestIdle if that would preferred by the group). This API is based on some of our experience in scheduling idle work as part of the Blink Scheduler project (there are more details in the Blink scheduler talk <https://docs.google.com/presentation/d/1vqqBwDbnwrCz0P5JX_fxVQd0Q5KmVZdB_hk6RLNgO2Q/edit> we gave during BlinkOn). The API is still at an early state, but this seems like an appropriate thread to present an early draft. The goal of this API is to enable page authors to schedule background work which is only run when the browser is idle. In addition, it provide these callbacks with an estimation of how long they can continue execution without causing jank. We think this API might be expressive enough to approximate the execute when idle use cases of setImmediate through a polyfill, and also provides some extra capabilities - e.g., enabling longer running (i.e., >16ms) work to be done only during times when the browser isn't actively animating frames, thus avoiding any jank. We would welcome any comments on the draft spec. It is available at: https://docs.google.com/document/d/1ZgYOBi_39-N6AbjL99qesiDagaSTbpN0R6CrSVK8NE4/edit# Cheers, Ross and Ilya On 24 June 2015 at 10:55, Hiroshi Kawada <kawada.hirosi@gmail.com> wrote: > I'm sorry, but I didn't explain enough. > > setImmediate has 3 use cases: > > 1. Executing after I/O(Layout,Rendering). > > requestAnimationFrame covers this use case, but it's not correct meaning.. > Real-world developers use setTimeout(fn,0). Microsoft developers uses > setImmediate(fn). `setIdleTask` is the best solution. > > 2. Dividing heavy processing. > > Generators(ES6) covers this use case, which contains Image decoding. Web > Workers also can help this use case. Some developer use > setImmediate/setTimeout, but it's incorrect. > > 3. Executing when thread are idle. > > This use case is very similar to no.1. Developers may use setTimeout(fn,0) > or setImmediate(fn). > requestAnimationFrame also covers this use cases. But it's not correct > meaning. Generators(ES6) can help us, but sometimes it's not useful. It > does not completely cover. `setIdleTask` is the best solution. > > > > > > On Wed, Jun 24, 2015 at 5:28 PM, Todd Reifsteck <toddreif@microsoft.com> > wrote: > >> Although I agree the name is suboptimal, 5% real-world web usage in >> Microsoft Edge is quite high usage to consider renaming or removing an >> existing API. 5% real-world usage hints that there is some demand for the >> functionality the API provides even though it is only implemented in 1 >> browser. >> >> >> >> Can you please elaborate on the ES6/7 feature that has the low priority >> callback characteristic of setImmediate? >> >> >> >> -Todd >> >> >> >> *From:* Hiroshi Kawada [mailto:kawada.hirosi@gmail.com] >> *Sent:* Wednesday, June 24, 2015 12:09 AM >> *To:* Todd Reifsteck >> *Cc:* public-web-perf@w3.org >> *Subject:* Re: setImmediate usage on the web >> >> >> >> I think setImmediate is too vague. Web developers just make callback >> executing after I/O(Layout/Rendering) or waiting for that thread gets idle. >> Some ES6 features that new browsers are already supported and >> requestAnimationFrame API covers this use case. >> >> >> >> So, we need to choose these 3 idea : >> >> >> >> 1. rename setImmediate to setIdleTask ... separate out two use >> cases(requestAnimationFrame and setIdleTask). >> >> 2. remove this spec. ... ES6/7 will cover this use case. >> >> 3. keep on this spec ... waiting for other idea or usage. >> >> >> >> >> >> On Tue, Jun 23, 2015 at 3:34 AM, Todd Reifsteck <toddreif@microsoft.com> >> wrote: >> >> I promised a few weeks ago to come back to the Web Performance Group >> with data on setImmediate usage within Microsoft Edge. Upon examining the >> data, I found that it required more parsing and analysis because the usage >> was much higher than I expected. What I discovered was that the usage was >> much higher in scenarios where setImmediate was guaranteed to be available >> such as Windows Store applications. >> >> >> >> *% of Navigations that include a usage of setImmediate* >> >> · Microsoft Edge browser navigations—4.73% >> >> · All instances of edgehtml.dll (including apps)—21..88% >> >> >> >> -Todd >> >> >> >> >> >> >> >> -- >> >> KAWADA Hiroshi >> >> Web Developer (JPN) >> >> http://hiroshik.info/ >> > > > > -- > KAWADA Hiroshi > Web Developer (JPN) > http://hiroshik.info/ >
Received on Wednesday, 24 June 2015 21:11:24 UTC