wp_presentation vs wl_surface_frame

[Pekka Paalanen]

On Thu, 26 May 2022 10:25:24 +0300
Maksim Sisov <msisov at 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
-------------- 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/20220527/ac73287a/attachment.sig>