Re: Any Explainer for "After Paint" API?

Historically there was an explainer for requestPostAnimationFrame
<https://github.com/WICG/request-post-animation-frame/blob/main/explainer.md>
 api.

More recently there is work brewing for a new proposal under the prioritized
task scheduling <https://wicg.github.io/scheduling-apis/> apis.  Previously
this was known as scheduler.render
<https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-task-scheduling.md#schedulerrender>
but
more recently has evolved into scheduler.yield({ waitForRender: true })
<https://github.com/WICG/scheduling-apis/issues/95>.

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 <http://aka.ms/weboutlook>
>