mithro
commented
9 years ago I'm confused here.
@igrigorik commented 13 days ago in #1
(based on a video chat w/ Michael)... cpuTime looks good. wallTime is better handled via duration attribute (see #3), which we can update to capture the total time to process the frame, instead of defining it as time between startTime's of subsequent frames. This allows developers to (a) detect if they're exceeding the frame budget, and if so (b) by how much.. instead of just getting a 'previous frame was painted 33ms ago'.
Which my understanding meant;
- duration was going to be "wall time" to render a frame,
- cpuTime was going to be "cpu time" to render a frame.
- vsync interval is calculated by working on the difference between two start times.
It seems that the discussion has moved onward somewhat and this is no longer the case?
Now some specific comments on this change.
Looking at the new definition of duration;
The <code>duration</code> attribute will return a <a href="http://www.w3.org/TR/hr-time/#domhighrestimestamp"><code>DOMHighResTimeStamp</code></a> with the duration of the frame, computed by subtracting the <code>startTime</code> of the current frame from the next possible v-sync boundary, or <code>startTime</code> of the next frame, if available. <code>duration</code> should capture the entire wall-clock duration of the current frame, INLCUDING any idle, blocking or descheduled time.</p>Its starts by saying that "duration = nextFrame.startTime - currentFrame.startTime", which because startTime is wall time, must also be wall time. Then it goes on to add some extra clarification statements that only make sense if duration was defined in some other way, such as time to render.
It should also be noted, with this definition, the duration is thus always going to be a multiple of the vsync interval. It gives the person no idea how much of the frame budget is being used.
This attribute must return a <a href="#bib-HR-Time">[High Resolution Time]</a> duration giving the actual wall-clock time used to process this frame EXCLUDING any idle time. The user agent SHOULD include the time spent on JavaScript execution, accessing and modifying the DOM and CSSOM, and other relevant processing operations required to render the frame (e.g. layout, style recalculations, painting, and so on).With this definition I think idle time definitely needs some clarification and the text you have added to the duration would actually make sense here. Reading this for the first time, I would have assume idle time means any time you are not rendering - which to me would include time that you are not running such as being descheduled.
igrigorik
natduca
vmpstr
mpb
Updating description for 'duration' and 'cpuTime' parameters for issue #3.
This clarifies a few points: 1) duration is measured as per requestAnimationFrame's definition of "start time" until the next VSYNC boundary this frame can make. This means duration will be approximately 16, 32, etc for ~60 FPS, depending on if you made or missed a particular deadline. It is a binary signal showing that you are missing deadlines.
2) 'cpuTime' captures wall clock EXCLUDING idle time. It is meant to show how much headroom you have when you make a deadline, or how much you missed by, when you miss one (or more.)
3) cpuTime is not an OS-level CPU time, it continues counting if the thread is descheduled and is a MAX() not a SUM() of all concurrent threads processing (if there are more than one thread). This is intentional because as a web developer, you have some amount of resources to use and are trying to use them to achieve a desired effect (smoothly!) It is the kernel and the user agent's job to manage system resources, and distribute time fairly.
Please let me know if the wording is clear, and if this makes sense in a vendor-agnostic way. Thanks!