WebPerfWG call minutes - Feb 14 2019
Shubhie Panicker, Todd Reifsteck, Thomas Kelly, Steven Bougon, Scott Haseley, Philippe Le Hegaret, Philip Walton, Nate Schloss, Markus Stange, Charles Vazac, Stefan Zager, Benjamin De Kosnik, Andrew Comminos
Shubhie: we’ve reviewed the proposal @ TPAC and we’ve been working with partners.
Stefan: we’re working towards on origin trial (OT) and APIs are subject to change based on OT
… riC passed idle deadline which provides a best guess for amount of time left to run application code before other urgent work - e.g. input events. This roughly maps to next rendering.
… we’ve been talking to React team and Maps team at Google.
Todd: I’m working with a number of teams at Microsoft to gather feedback, in ~month I should have feedback on usability and value of this API. Stay tuned.
Stefan: the feedback on rIC is that they want a signal beyond input event (e.g. currently we return 0 if input is pending); the sophisticated developer use case here is if you’re writing your own render loop.
Ryosuke: this API may be problematic for us because we rely on underlying OS that may change screen refresh rate (e.g. throttle to 60 or even 30hz)...
… my suggestion is to align with how some of the native APIs tackle this, which is expose this information via rAF.
Alternative suggestion: expose this as an argument to rAF or in a callback form.
Stefan: … there is no way to know the hardware refresh rate for iOS?
Ryosuke: I don’t think there is an API, we would likely have to guess and the system may change the refresh rate.
… raf in WebKit fires immediately after vsync, we’re changing this to align with other browsers which is firing after browser finished its work.. However, this has the gotcha that it’s unpredictable.
Stefan: so you’re don’t objecting to exposing information but would prefer to see it exposed via rAF. Why only rAF though? The main utility here is while you’re doing the work inside of the frame
AI (Stefan, Shubhie, Ryosuke): follow up offline to understand the limitations and proposed rAF considerations here.
Todd: Like this API. Currently the time exposed is until rendering steps behind, but then there is also the expected vsync time. Could or should we expose the vsync information?
Stefan: Speaking for Chrome, I don’t think we can observe the vsync time. We have looked into this.
TODO(szager): link to what we found for exposing vsync.
Todd: yep, just asking the question, not saying this is a blocker
Stefan: Webkit currently behaves differently from other browsers; currently its scheduled after vsync, whereas other browsers run rAF immediately before we run our update pipeline.
… this is observable in WPT tests
… why can’t we have both? could we run code immediately after render steps are complete?
… developer feedback is that they also want to avoid forced layouts and currently there is no way to gauge that — by scheduling in this slot they can rely on clean read back.
Ryosuke: so, this is ~requestPostAnimationFrame?
Stefan: yep, or rAF could take two callbacks: one that runs before vs after.
… currently rAF does not accept second, we’d have to do some investigation if there is any
Ryosuke: (API bikeshed): maybe an option dict
Markus: this was suggested for FF before (https://www.w3.org/Bugs/Public/show_bug.cgi?id=28644 ), I think this makes sense.
Stefan: we have the “VSYNC” signal from GPU process but it’s not directly vsync.. We need to be a little careful here.
… we’ve found lots of past requests from this.
Todd: definitely see need for this API
Ryosuke: that’s precisely why WebKit implementation is as it is.. It buys the developer the most amount of time.
Shubhie: clean reads is another use that’s come up a number of times
Stefan: doesn’t seem to be controversial.
Shubhie: FYI, scheduling API’s we’re exploring are: Overall explainer, I2I on blink-dev, TAG review
Stefan: we’re considering doing dynamic framerate throttling like in WebKit, and considering exposing an API for it too.. E.g. game developer wanting to drive 30hz instead of 60Hz because the latter is janky.
Markus: where can we provide feedback?
Yoav: can we spin up an incubation repo?
AI (Stefan, Shubhie, Yoav): create repos on WICG for scheduling efforts.
Nicolás: recently landed spec changes we’ve discussed in the past…
… both mark and measure now accept optional “detail” field
… also both accept timestamp
… we added new measureWithOptions because overloading old method is becoming confusing
… this new API accepts timestamps in addition to strings as well as “detail” field
… all optional parameters go into the dictionary
… all the methods are no longer void, they now return the mark/measure object
… also, we allow PerformanceMark to be constructed to accommodate Ben Kelly’s SW use case where you don’t want it ot be added to the timeline
… all the changes are in the draft, looking for feedback..
Ryosuke: why new method, can we override existing?
Nicolás: it’s not strictly necessary we could make it work but the feedback was that it would be simpler and more ergonomic for developers
Philip: I agree with Ryosuke, measureWithOptions feels a little awkward
Yoav: are there any compat concerns here?
Tim: we did the research and we concluded that compat is not an issue
Philip: Nic and Charlie recommended new method, I think it’s more of a personal preference
Charles: my perspective was that implementation and developers might have easier time with new method
Philippe: measure and measureWithOptions seems harder to remember to me
Charles: my comment was based on addEventListener pains we encountered, would like to avoid this…
AI: update spec to use measure() and publish L3 draft
AI: gather more feedback from developers once we have L3 draft published
Phillippe: I’m publishing L2 REC next week, I can publish L3 at the same time.