06:45 vyivel: noticed this: https://lists.freedesktop.org/archives/wayland-devel/2024-April/043570.html
06:45 vyivel: would adding wl_object_get_{id,class}() be correct solution?
06:47 vyivel: afaict there's no public functions operating on wl_object at the moment
12:03 wlb: wayland Merge request !390 opened by Kirill Primak (vyivel) util: introduce wl_object_get_{id,class}() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/390
15:54 wlb: weston Merge request !1512 opened by Sebastian Urban (surban) desktop-shell: shrink windows not to be obscured by input panel https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1512
18:15 colinmarc: clients are generally going to bind either presentation time or the new sync stuff, right? does using both together ever make sense?
18:25 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 :)
18:56 danieldg: my understanding is: presentation-time is about past frames, and syncobj is about future frames
18:57 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'
19:30 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"
19:31 kennylevinsen: Without syncobj, the compositor can end up blocked on stuff that wasn't ready through implicit sync so it drops frames
19:32 kennylevinsen: without presentation time you might end up with wrong frame pacing or have lipsync issues
19:35 colinmarc: hrm, okay, that helps, thanks. is presentation time used by games to minimize latency as well?
19:36 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?
19:55 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
19:56 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
23:22 riteo: hey sorry quick question about commit timing: is it meant to be used only by WSI or also by clients directly?
23:23 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?