- From: Noam Rosenthal <nrosenthal@google.com>
- Date: Fri, 13 Sep 2024 16:30:25 +0100
- To: Michal Mocny <mmocny@google.com>
- Cc: "Andy Luhrs (HE/HIM)" <aluhrs@microsoft.com>, Scott Haseley <shaseley@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Incidentally, it's possible to polyfill `requestPostAnimationFrame` today using element timing. See gist: https://gist.github.com/noamr/3ffb223d1a560db3a9a066d7117332c8 On Tue, Sep 3, 2024 at 8:39 PM Michal Mocny <mmocny@google.com> wrote: > > Historically there was an explainer for requestPostAnimationFrame api. > > More recently there is work brewing for a new proposal under the prioritized task scheduling apis. Previously this was known as scheduler.render but more recently has evolved into scheduler.yield({ waitForRender: true }). > > Some nuances: > > With requestAnimationFrame (or the proposed requestPostAnimationFrame) you ask for a callback before/after the next rendering opportunity. But you also force the scheduler to schedule that rendering opportunity -- even if there didn't need to be one, yet. > > You typically only get one chance to do this, per vsync. > There is no way to observe a rendering opportunity without also requesting one. > With the prioritized task scheduling variant, the semantics are different: you yield until after the next render if it is needed. We might not need to actually schedule rendering if there isn't rendering needed. > > Rendering opportunities are typically scheduled with a task priority which is dynamic. > > In chromium it starts at normal priority and gets boosted to very high priority after a timeout, or after any new trusted user interaction. > There was previously no way to request rendering to have any specific priority. > With the prioritized task scheduling variant, when a high priority task explicitly waits on rendering... this might be used as scheduling a hint. > > > On Tue, Sep 3, 2024 at 3:12 PM Andy Luhrs (HE/HIM) <aluhrs@microsoft.com> wrote: >> >> Hey all, >> >> Is anyone aware of an existing explainer/discussion after some sort of "requestAfterPaint" API idea? The concept seems to be discussed pretty often, and solved with a double-rAF or rAF+setTimeout, but we're interested in discussing a real solution. Figured I'd ask if there's prior art before kicking off an explainer myself. >> >> Thanks, >> Andy Luhrs >> >> Sent from Outlook
Received on Friday, 13 September 2024 15:30:42 UTC