Re: Any Explainer for "After Paint" API?

On this timing-related subject, is there any movement to adding variable
refresh rate support to everything that does animations (Canvas, WebGL,
requestAnimationFrame, etc)?

VRR is where *the** software decides *when* VSYNC is*, rather than the
monitor/OS.

In fixed-Hz mode, the GPU has an independent VSYNC clock.
In GSYNC/FreeSync mode, the monitor waits for the software+GPU to deliver a
frame.

In essence, VSYNC timing is decided by the application developer in
userspace (e.g. Javascript level, in the case of browsers)

(BTW, I added HDR canvas requestAnimationFrame to https://beta.testufo.com but
only works in Chrome/Edge and not Safari)

Thanks,
Mark Rejhon
Blur Busters / Rejhon Technologies Inc.

--- An Important Note From Our Legal Beagles ----
*This message is intended solely for the named recipient, and may contain
confidential information protected under applicable law. Any unauthorized
dissemination, distribution, copying, or the use of information contained
in this email is strictly prohibited. If you have received this
communication in error, please notify the sender and delete this email
immediately.*
--- Fin ---


On Tue, Sep 3, 2024 at 1:40 PM Michal Mocny <mmocny@google.com> wrote:

> 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>
>>
>