Re: WebPerfWG design call - Thursday Feb 14th @ 11am PST

Hey all!

Minutes from today's call are now available
<https://docs.google.com/document/d/e/2PACX-1vTO8f2vYWLHDwk57Zk4FYNMkSBaUkppAJelPT26uMYu_aAsF03XXonmVLHm_ULOohPqr_tyhZNIHGxf/pub>
.
Copying them here for safe keeping:

WebPerfWG call minutes - Feb 14 2019

WebPerfWG call minutes - Feb 14 2019
Participants

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
Administrative

   - Meeting is being recorded, we will post on YouTube.
   - Next call: March 8th @ 11AM PST, with next call week after that

Scheduling API: frame budget
<https://www.google.com/url?q=https://github.com/szager-chromium/timeUntilNextFrame/blob/master/explainer.md&sa=D&ust=1550188675807000>


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
Scheduling API: post-animation-frame callback
<https://www.google.com/url?q=https://github.com/szager-chromium/requestPostAnimationFrame/blob/master/explainer.md&sa=D&ust=1550188675810000>

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
<https://www.google.com/url?q=https://www.w3.org/Bugs/Public/show_bug.cgi?id%3D28644&sa=D&ust=1550188675812000>
),
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
<https://www.google.com/url?q=https://github.com/spanicker/main-thread-scheduling/blob/master/README.md&sa=D&ust=1550188675813000>
, I2I on blink-dev
<https://www.google.com/url?q=https://groups.google.com/a/chromium.org/d/msg/blink-dev/eLq8t56CbaQ/KdbOY7ZHCwAJ&sa=D&ust=1550188675814000>
, TAG review
<https://www.google.com/url?q=https://github.com/w3ctag/design-reviews/issues/338&sa=D&ust=1550188675814000>

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.
UserTiming L3
<https://www.google.com/url?q=https://w3c.github.io/user-timing/&sa=D&ust=1550188675815000>

Nicolas: 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?

Nicolas: 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.

On Tue, Feb 12, 2019 at 1:59 PM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all,
>
> Let's meet up and chat about new and exciting WebPerf APIs. (hangout link
> <https://meet.google.com/nog-ttdz-myg?hs=122>)
>
> The agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.q4442yui6g1m>
> currently includes:
>
>    - Scheduling API: frame budget
>    - Scheduling API: post-animation-frame callback
>    - Scheduling API: overall plan
>    - UserTiming L3
>    - In progress resource requests
>
> Feel free to add other things you think needs discussing.
>
> See y'all there! :)
> Yoav
>
>