Re: Next call - October 16th 11am PST (TPAC planning, Triage and Design)

Hey all,
Here's the updated link to the Scheduling case studies deck:
https://docs.google.com/presentation/d/1HGBOAfVhmWoyOt2ETk-1Y2dOvuMyRnQ5AF7VrPBvfX0/edit#slide=id.g4506b1db01_0_77


On Tue, Oct 16, 2018 at 9:54 PM, Yoav Weiss <yoav@yoav.ws> wrote:

> Thanks to all who attended. Minutes from the call can be found here
> <https://docs.google.com/document/d/e/2PACX-1vRlt2UBBEVuaBf_M23KE9l5O4OrdNrHVsrotiEDKr_rNTvIs3aGlidBiA2NWPyizHsCgBrD1H8-_Be6/pub> or
> below
>
> WebPerfWG - October 16th minutes
>
> Present: Tim Dresser, Yoav Weiss, Nicolas Pena, Ryosuke Niwa, Andrew
> Comminos, Charles River, Charles Vasac, Eric Faust, Gilles D, Nathan
> Schloss, Nic Jansma, Philip Walton, Philippe Le Hegaret, Shubhie Panicker,
> Shweta Joshi, Todd Reifsteck, Vladan D, Xiaoqian Wu
>
> Chair: Yoav Weiss
>
> Scribe: Tim Dresser
>
> Next Meeting: Monday November 5th at 11:00am PST
>
> Yoav: Please take a look through the agenda
> <https://www.google.com/url?q=https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit?ts%3D5ba207d4%23&sa=D&ust=1539722904298000>,
> and write yourself down as a scribe for some topic.
>
> Triage
>
> Performance-timeline
>
> https://github.com/w3c/performance-timeline/issues/105
> <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/105&sa=D&ust=1539722904299000>
>
> Nicolas:
>
> Paint timing may fire very late due to a page being backgrounded.
>
> The current visibility API doesn’t look because you can’t see historical
> entries.
>
> Yoav:
>
> This shouldn’t block the performance timeline spec.
>
> Phillippe:
>
> What about out of viewport resources?
>
> Todd:
>
> There are also out of viewport iframes etc. Maybe we want a general
> “performance may be impacted” flag.
>
> Yoav:
>
> What’s the visibility state of out of viewport iframes?
>
> Todd:
>
> Currently if the tab is visible, all frames are considered visible.
>
> This is also discussed in this
> <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/29&sa=D&ust=1539722904302000> page
> visibility issue.
>
> Yoav:
>
> A page visibility entry which gets buffered could address the page
> visibility issue, but this doesn’t fix the iframe case.
>
> Nate:
>
> What if for each entry, we have a boolean “was this potentially impacted
> by throttling”?
>
> Todd:
>
> There are a lot of heuristics at play here though, which are changing all
> the time. We might want to focus on specific occurrences that devs should
> be able to understand.
>
> Ryosuke:
>
> Why do we need a new API?
>
> Yoav:
>
> We need a new API to track visibility state before JS has been executed.
>
> Ryosuke:
>
> Just executing this script shouldn’t be expensive. What’s the use case
> where the user changes visibility before the page paints.
>
> Yoav:
>
> The page is loaded in the background, and so javascript to monitor
> visibility doesn’t get to run until we switch to the tab.
>
> Gilles D:
>
> We need visibility on the timeline.
>
> https://github.com/w3c/performance-timeline/issues/81
> <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/81&sa=D&ust=1539722904306000>
>
> Yoav:
>
> This adds the buffered flag. We want to unite the buffering logic across
> all specs. We may want to postpone this until the big navigation / resource
> timing unification in L3.
>
> This logic should live in the performance timeline.
>
> Let’s rip out the buffered flag in L2.
>
> Instead of buffering until onload, have a maximum number of entries.
>
> Nic:
>
> There’s no reason for user timing to have a max buffer size. The same
> model may not apply everywhere.
>
> Yoav:
>
> We could tweak the size per entryType, but keeping the same model for all
> buffered entryTypes.
>
> For user timing, we could set no buffer limit (or set it to no limit).
>
> Todd:
>
> Who is this issue assigned to? We need someone to own this.
>
> Yoav:
>
> I’ll drive it.
>
> Todd:
>
> Core goal - give analytics providers the data they want, while not
> bloating the web.
>
> Resource Timing punted for this week.
>
> Scheduling API - deck
> <https://www.google.com/url?q=https://docs.google.com/presentation/d/1NSZZe7qEOX4qYHjvTz0VTlwBoj368ZrDcMCzwpifPYk/edit?usp%3Dsharing&sa=D&ust=1539722904310000>
>
> Shubhie:
>
> We’ve dug into existing schedulers: React, Google Maps,
>
> React schedules work on rAF (raced with setTimeout). The scheduler then
> postMessages itself to execute the next task.
>
> 4 priority levels: immediate, user blocking, normal, idle.
>
> Each priority has an “expiration time”. Expired tasks are the most
> important.
>
> Tries to do as much work as possible until the frame deadline comes up.
> All expired tasks are executed synchronously.
>
> Dynamically figures out frame rate, starting at 30fps.
>
> Nate:
>
> This all sounds right. Planning to add a fifth priority “logging”. It’s a
> bit more important than idle, but shouldn’t block anything user visible.
>
> Ryosuke:
>
> You mentioned updating priorities. What updates these priorities? Are they
> only updated in the scheduler itself, or in user code?
>
> Nate:
>
> Only user code.
>
> Shubhie:
>
> The framework drives the priority. User code doesn’t even know about the
> scheduler.
>
> Todd:
>
> The React framework chooses which callbacks should have which priority.
>
> Nate:
>
> Aim is to have the React Scheduler used for non-React code.
>
> Shubhie:
>
> The Google maps scheduler is similar, it also uses rAF to drive the
> scheduler. It classifies work into 4 categories: Input, Animation,
> Rendering, Other
>
> Input, Animation & Rendering are all executed synchronously within rAF.
>
> Other is executed in an asynchronous way using postMessage.
>
> Does frame rate throttling, especially during startup / transition to 3D
> earth view.
>
> Todd:
>
> The details are going to be pretty hairy.
>
> Ryosuke:
>
> This feels a lot like resource loading before the fetch spec existed.
>
> Figuring out how these APIs fit together feels important.
>
>
> On Thu, Oct 11, 2018 at 11:35 AM Yoav Weiss <yoav@yoav.ws> wrote:
>
>> Hello all,
>>
>> The next WebPerf WG call will be on Tuesday next week, October 16th 11am
>> PST. (with a *different hangout *link
>> <https://hangouts.google.com/call/pt6GicuSLwEZvrc3semFAAEI>, see below)
>>
>> The call will be a mix of subjects, as we want to talk about TPAC's F2F
>> agenda, discuss some issues as well as complete the discussions from last
>> week regarding the Scheduling API.
>>
>> Tentative agenda
>> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.ohc3prc50j0w>
>> :
>>
>>    -
>>
>>    TPAC agenda
>>    <https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#>
>>    -
>>
>>    Performance-timeline
>>    -
>>
>>       https://github.com/w3c/performance-timeline/issues/105
>>       -
>>
>>       https://github.com/w3c/performance-timeline/issues/81
>>       -
>>
>>    Resource Timing
>>    -
>>
>>       https://github.com/w3c/resource-timing/issues/166
>>       -
>>
>>       https://github.com/w3c/resource-timing/issues/165
>>       -
>>
>>       https://github.com/w3c/resource-timing/pull/163 vs
>>       https://github.com/w3c/resource-timing/pull/168
>>       <https://github.com/w3c/resource-timing/pull/168>
>>       -
>>
>>    Scheduling API
>>
>>
>>
>> Feel free to add to the agenda if you there's something else you want to
>> discuss, and we'll see how we fit that in.
>>
>> Note that due to last call's hangout mishaps, we'll be using a *different
>> hangout link <https://hangouts.google.com/call/pt6GicuSLwEZvrc3semFAAEI>*.
>> Please try to connect a couple of minutes before and let me know on IRC or
>> elsewhere if you're running into any issues on that front.
>>
>> See y'all next week!
>> Yoav
>>
>