Bugzilla

(In reply to Markus Stange [:mstange] from comment #13)
> (In reply to Kenny Levinsen :kennylevinsen from comment #0)
> > This frame-callback is *not* called consistently on vsync, but simply when and if the compositor wishes for you to render. It is, however, guaranteed to be called a time granting us the best chance of reaching the next surface sampling deadline (i.e. vblank).
> 
> I'm curious, does this callback come with some kind of "budget" information, i.e. a CPU time and GPU time budget, that we need to stay under in order to hit the deadline?

No, when the next deadline will occur is not known ahead of time. For example, on a VRR-enabled compositor like sway, the refresh rate might be 45Hz one moment, but 144Hz the next due to moving the mouse. It's entirely controlled by whether and when applications on that screen post buffers, as well as the refresh rate limits of the monitor.

The frame callback itself only carries a timestamp (without defined base, useful for simple animations), while precise presentation timing (with well-defined base) can also be requested for delivery after a frame gets presented. This can be used to estimate the frame time and guess when the next presentation (and thus deadline) is *likely* to occur.

(In reply to Markus Stange [:mstange] from comment #13)
> (In reply to Kenny Levinsen :kennylevinsen from comment #0)
> > This frame-callback is *not* called consistently on vsync, but simply when and if the compositor wishes for you to render. It is, however, guaranteed to be called a time granting us the best chance of reaching the next surface sampling deadline (i.e. vblank).
> 
> I'm curious, does this callback come with some kind of "budget" information, i.e. a CPU time and GPU time budget, that we need to stay under in order to hit the deadline?

No, when the next deadline will occur is not known ahead of time. For example, on a VRR-enabled compositor like sway, the refresh rate might be 45Hz one moment, but 144Hz the next due to moving the mouse. It's entirely controlled by whether and when applications on that screen post buffers, as well as the refresh rate limits of the monitor.

The frame callback itself only carries a timestamp (without defined base, useful for simple animations), while precise presentation timing (with well-defined base) can also be requested for delivery after a frame gets presented. This can be used to estimate the frame time and guess when the next presentation (and thus deadline) is *likely* to occur (which, for fixed frame-rate setups, is of course very precise).