https://lists.w3.org/Archives/Public/public-web-perf/2015Jun/0126.html
Ross: [brief overview of the API and motivations]
... 8 months ago, we wanted to host background task in the scheduler
... JS garbage collection, etc.
... implementation was based partly on rendering tasks
... idle time, etc.
... the internal API looks similar to the one we're proposing
... and we think it would be useful
... so scheduling background task
... long running processing, prerendering of content, etc.
... could do with a worker
... but needs access to the DOM
... the API uses a callback
... and it become eligible to run at idle times
... so could not run for some time
... timeout parameter gives some guarantee
... deadline objects help with figuring future expectations
... any questions?
[none heard]
Ross: some discussion around setImmediate with a deadline
... don't hink it's the same
... but we could do some polyfill of setImmediate use cases
... but there are different set of use cases
... setImmediate is an API for yielding from the critical path
... ie not get in the way of critical path
... requestIdleCallback (IRC) is different from that
... doesn't get in the way of rendering either
... you get a setImmediate callback (SIC) after each rendering loop
Todd: yes, current impl of SIC can block rendering
... other that that, we do share the rendering idle time semantic
... but don't stop when idle time is over
Ross: we can polyfill SIC really easily, by fallback using RAF
... so your work will be processed if the next frame goes out
Todd: somewhat reasonnable
... IRC seems an implementation detail that is exposed
... RAF would do all of the RIF if wai until next frame
Ross: the spec says that if if you call IRC from within an other IRC
... it will run in the next idle period, not the current one
... so if you have a lot of work, you can do some of it up until the deadline and scheduled yourself for the next idle
... if you work is 5ms and deadline is 5ms, you don't want to reschedule within that same idle period
Yoav: could be multiple idle period inside the same frame
Ross: current impl is only one idle
... when not drawing frames, we have 15ms chunks
Todd: if it has to wait for the next idle, is that a requirement or a default behavior?
... if there is time remaining in the idle period, why not?
Ross: good point. the user should be aware of the remaining deadline
... something we could add to the spec after discussion
... but default should be next idle period
... I'd like to see some use cases first
... but should be easy enough to add
Ilya: curious on use cases as well
Todd: RAF is about once per frame
... IRC is about work during idle time
Ross: if you know you had that work to do, why don't you do it within the same IRC?
... if you have multiple idle callback, you may want to yield to the one
... you can build on top as part of libraries
Todd: you can do that, but we could also build the abiility in the API
Ilya: what's the next steps?
... I do think we can polyfill SIC using IRC
Todd: saying it can polyfill isn't the same as the adoption
... should we introduce a new named API or change the existing one?
Ross: you do have about 5% usage of setImmediate but I think it's using for immediate task
... if we change that, you will loose it
... would be confusing for the name
... immediate or in the background?
Yoav: I agree it would be confusing
Todd: I agree
... the name doesn't state Idle
... IdleRequestCallback is a better name
Ross: I do believe there are use cases for setImmediate, so a polyfill or a direct impl is valid
Yoav: is that true in the background as well?
Todd: just like RAF
... setImmediate doesn't run in a non-visible task
Ross: background tab would run for 10s before being stopped
... open for changes as long as we don't use a lot of energy
Ilya: that behavior would affect RAF as well
Todd: we can cover that into the spec
Ilya: are we ok to adopt IRC as a top level spec?
Todd: don't have a strong enough objection to block
Plh: would be good to have a polyfill for setImmediate using requestIdleCallback and RAF
long requestIdleCallback(IdleRequestCallback callback [, timeout ] );
<scribe> ACTION: plh to create a repo for requestIdleCallback
<trackbot> Created ACTION-157 - Create a repo for requestidlecallback [on Philippe Le Hégaret - due 2015-07-22].
https://github.com/w3c/resource-timing/issues/27
Ilya: you can use RT to monitor resources uses by style sheets
... with the cors attribute
Todd: we agree we should block
https://w3c.github.io/resource-timing/#privacy-security
Ilya: [looking at proper place]
<scribe> ACTION: Ilya to make a proposal for fixing CORS issues on RT
<trackbot> Error finding 'Ilya'. You can review and register nicknames at <http://www.w3.org/2010/webperf/track/users>.
Todd: this has been reopened by Mozilla
... and we're clamping at 1-5 nanoseconds now
... should we spec that?
... proposal is to clamp at least 1 nanosecond in the spec
<igrigorik> Chrome: https://code.google.com/p/chromium/issues/detail?id=506723
Ilya: chrome and webkit are clamped at 5 microseconds
Eli: it looks like we're at 5 microseconds
Resolved: we're clamping at at least 5 microseconds
<scribe> ACTION: Todd to clamp HR-TIME at 5 microseconds
<trackbot> Created ACTION-158 - Clamp hr-time at 5 microseconds [on Todd Reifsteck - due 2015-07-22].
https://github.com/w3c/navigation-timing/issues/22
Todd: feedback was, why did we removed them from the spec?
Plh: [history and possibilities]
Ilya: given the deployment, we can't drop them
Todd: agree
typedef double DOMHighResTimeStamp;
readonly attribute unsigned long long navigationStart;
[different time origns]
Todd: if we do both, we can only expose the navigation and timing attributes in the Window context
http://w3c.github.io/hr-time/#idl-def-Performance
Plh: but Performance is exposed to Workers...
interface Performance {
readonly attribute PerformanceTiming timing;
readonly attribute PerformanceNavigation navigation;
};
partial interface Window {
[Replaceable] readonly attribute Performance performance;
};
for hr-time-2:
[NoInterfaceObject, Exposed=(Window,Worker)]
interface GlobalPerformance {
[Replaceable]
readonly attribute Performance performance;
};
Todd: I'll take this into the issue
Michael: it sounds to me that everyone is ok to get rid of standalone constructor but use the performance object to get a new one
... other that than the rest of the spec should work
... like that the performance object will be clear
Plh: +1
Eli: +1
Michael: see #35
https://github.com/w3c/performance-timeline/pull/35
https://github.com/w3c/resource-hints/issues/37
Ilya: in a world of preconnect, is there a use for prefetch?
... there are some use cases from blink-dev
... preconnect can be expensive
... so probably makes sense to have dns-prefetch
... it's implemented as far as I know
... ok to add to resource hints spec?
Todd: +1
[Ilya will follow up]
Ilya: I'm not aware of any impl that are using the recommended marks
... they define their owns
... given the lack of adoption, I'm inclined to remove those
... we may come up with new ones
... but not a strong argument to do so
Todd: makes sense
Eli: agree
... drop the recommended mark names
... in Firefox OS, we made our owns for our apps
Ilya: so are those marks useful?
Eli: it's an ad-hoc thing. every app will have different asset loading strategy/order
... so the marks are vague on purpose
<scribe> ACTION: Eli should provide references at our recommended mark names in firefox os are used in internal apps
<trackbot> Created ACTION-159 - Should provide references at our recommended mark names in firefox os are used in internal apps [on Eli Perelman - due 2015-07-22].
<scribe> ACTION: plh to drop recommended marks in user timing
<trackbot> Created ACTION-160 - Drop recommended marks in user timing [on Philippe Le Hégaret - due 2015-07-22].
August 12