On Thu, 15 Jun 2023 16:58:12 -0500 Matt Hoosier <matt.hoos...@gmail.com> wrote:
> On Wed, Jun 14, 2023 at 7:13 PM Daniel Stone <dan...@fooishbar.org> wrote: > > > Hi Joe, > > > > On Wed, 14 Jun 2023 at 21:33, Joe M <brainsna...@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
pgpVzejJZF64P.pgp
Description: OpenPGP digital signature
