ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Guest3791 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest3861
teaper[m] has joined #wayland
Kelseyjgilbert[m] has joined #wayland
Net147 has joined #wayland
drakulix[m] has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest3877
<colinmarc>
clients are generally going to bind either presentation time or the new sync stuff, right? does using both together ever make sense?
Guest3861 has quit [Remote host closed the connection]
<colinmarc>
and should I implement commit-timing instead of presentation-time or those orthogonal? basically I'm a bit confused about the sync/timing landscape right now :)
kts has quit [Ping timeout: 480 seconds]
<danieldg>
my understanding is: presentation-time is about past frames, and syncobj is about future frames
<danieldg>
so presentation-time can help do A/V sync for videos, or help hint 'you should start working on frames earlier, you missed the deadline last time'
TheCaptain82970403198578471379 has joined #wayland
enick_190 has joined #wayland
<kennylevinsen>
syncobj is about "when is the GPU done so we can actually put the stuff on screen" while presentation time is "when did stuff make it to the screen"
<kennylevinsen>
Without syncobj, the compositor can end up blocked on stuff that wasn't ready through implicit sync so it drops frames
<kennylevinsen>
without presentation time you might end up with wrong frame pacing or have lipsync issues
<colinmarc>
hrm, okay, that helps, thanks. is presentation time used by games to minimize latency as well?
<colinmarc>
it seems like it could be, like, if my compositor is rendering on a fixed clock, the client could align its render clock to mine. or is that now how it's supposed to work?
rv1sr has quit []
coldfeet has quit [Remote host closed the connection]
<kennylevinsen>
No, the frame callback can do that. The presentation time is about knowing when the user actually saw the content, to account for latencies. Matched audio and video for example, or in a more extreme case, rythm games
<kennylevinsen>
So if you know the next frame will be seen by the user (not just drawn by the compositor) at some time T, you can better know what exact frame to draw for it to line up
gusnan has quit [Remote host closed the connection]
gallo has quit [Remote host closed the connection]
gusnan has joined #wayland
gallo has joined #wayland
bindu_ has quit [Remote host closed the connection]
bindu has joined #wayland
ivyl has quit [Quit: end of flowers]
riteo_ is now known as riteo
<riteo>
hey sorry quick question about commit timing: is it meant to be used only by WSI or also by clients directly?
<riteo>
I did an awful lot of research and asking around and I think I finally understood why we need fifo-v1, and it's definitely mainly for the WSI (or Vulkan libs, sorry, I don't know if that's the right word), but is commit-timing also meant to be used indirectly?
glennk has quit [Ping timeout: 480 seconds]
ivyl has joined #wayland
DodoGTA has quit [Remote host closed the connection]