W3C home > Mailing lists > Public > public-web-perf@w3.org > January 2015

[frame-timing] spec updates & measuring work/cpu-time

From: Ilya Grigorik <igrigorik@google.com>
Date: Thu, 8 Jan 2015 17:20:32 -0800
Message-ID: <CADXXVKo8E7xBaVzLZ=S1eN8jLQ9kxhZCrNN18O91QrpA--L-6w@mail.gmail.com>
To: public-web-perf <public-web-perf@w3.org>
Cc: Tobin Titus <tobint@microsoft.com>, Matt Woodrow <matt.woodrow@gmail.com>
Latest draft: http://w3c.github.io/frame-timing/

Highlights of recent updates:
- onframetimingbufferfull is now an EventHandler (matches other specs)
- PerformanceMainFrameTiming > PerformanceRenderTiming
- PerformanceRenderTiming: startTime and duration are now defined in terms
of rAF
- "cost" (previously known as "cpuTime") is removed from the spec

For the last bit on "cost" we've iterated on a couple of ideas and arrived
at a conclusion that (a) this is a hard problem that deserves more
discussion, (b) this functionality may be better handled as a separate perf
API/spec. A summary doc:


^ would love to hear any thoughts or feedback. In particular, I'll
highlight the three questions at the end:

(1) Should there be a standalone API for providing this sort of data to
developers? e.g. start() -> stop() interface that allows you to get a
profile between two arbitrary time points? If so, what kind of information
could/should we surface there?
(2) Can the cpu-time data be reliably obtained across all the various
(3) Other gotchas or alternatives we’ve not considered here?


P.S. Last but not least, we're working on implementing the current Frame
Timing draft in Blink:
Received on Friday, 9 January 2015 01:21:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:27 UTC