Refresh rates with multiple monitors

[Pekka Paalanen]

On Thu, 15 Jun 2023 16:58:12 -0500
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> On Wed, Jun 14, 2023 at 7:13 PM Daniel Stone <daniel at fooishbar.org> wrote:
> 
> > Hi Joe,
> >
> > On Wed, 14 Jun 2023 at 21:33, Joe M <brainsnacks at yahoo.com> wrote:
> >  
> >> Thanks Daniel. Do you know if wl_output instances are decoupled from each
> >> other, when it comes to display refresh?
> >>  
> >
> > Yep, absolutely.
> >
> >  
> >> The wl_output geometry info hints that each output can be thought of as a
> >> region in a larger compositor canvas, given the logical x/y fields in the
> >> geometry. Is the compositor able to handle the repaint scheduling in a
> >> refresh-aware way?
> >>  
> >
> > Yes.
> >
> >  
> >> I'm trying to get a better understanding of how these pieces interact to
> >> maximize draw time but still hit the glass every frame. The various blog
> >> posts and documentation out there are pretty clear when it comes to drawing
> >> to a single physical display, but less so when multiple displays are in use.
> >>  
> >
> > Per-output repaint cycles are taken as a given. You can assume that every
> > compositor does this, and any compositor which doesn't do this is so
> > hopelessly broken as to not be worth considering.
> >  
> 
> You can use the wp_presentation extension API to get real-time measurements
> about how long elapsed between the moment you submit an updated buffer and
> when it hits the glass. If you work backward from that number, you can
> figure out how long beforehand to start your drawing so that you can get
> minimally stale rendered contends but not drop any frames.

That's a bit inconvenient though. In order to find the deadline inside a
frame cycle, every time you start your animation you have to repeatedly
miss the deadline in order to probe where it is. Then you guess how
much margin you need to make it reliable enough to not miss the
deadline accidentally. Then, there are compositors who dynamically
adjust their own updates, moving the deadline around.

These are grave enough problems that I believe the consensus is that
minimizing latency to light is not realistically possible with the
existing protocols.

What the wp_presentation is good for is to estimate when your update
turns into light if you submit the update early enough, so you can get
e.g. A/V sync right or predict game state. Early enough is basically
committing a ready buffer when the frame callback of the previous
update returns. But that is not minimizing the sub-frame latency.
Depending on a compositor it may be maximizing it.

People have been thinking about new protocol extensions for a while,
but I haven't followed how far they got.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20230616/65415133/attachment-0001.sig>