On Thu, 26 May 2022 10:25:24 +0300 Maksim Sisov <msi...@igalia.com> wrote:
> Hello! > > I'm currently working on some begin frame issues in Chromium and I > started to wonder if we use available mechanism for synchronization > correctly. > > Wayland compositors may support wl_surface_frame and wp_presentation or > just wl_surface_frame. At the moment, Chromium uses both wp_presentation > to adjust own begin frame scheduling based on the presentation time. > Also, it utilizes wl_surface_frame just before attaching new wl_buffers > to wl_surfaces (we use dmabuf + zwp_linux_dmabuf). > > I wonder if using wl_surface_frame along with wp_presentation is > necessary except the cases when a window is fully occluded. > Hi, presentation-time feedback and frame callbacks are not quite equivalent. It is possible to get frame callbacks before the previous frame was actually presented, allowing you more time to draw and submit. Feedback with "presented" OTOH can only occur once the presentation timestamp is known, which usually means the KMS atomic commit has been replied with a KMS pageflip event in the compositor. If your question is about finding the optimal time to start drawing in order to minimize latency to screen, then I don't think there is a clear answer to that yet. Some compositors may automatically adjust when they send frame callbacks, others don't. Feedback "presented" definitely occurs after the current frame was presented, but it has no information about when the deadline for the next one is, so all you can do is draw immediately and hope the deadline didn't pass already. I didn't quite understand your explanation of what Chromium does. Can you describe the problem you have? Thanks, pq
pgpOHnJKZrKWc.pgp
Description: OpenPGP digital signature
