wp_presentation vs wl_surface_frame

[Maksim Sisov]

On 2022-05-27 11:43, Pekka Paalanen wrote:
> 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

Chromium has internal begin frame scheduling that adjusts self according
to the begin frame scheduling. It can adjust self using vsync
information from the presentation feedback it receives. The presentation
feedback won't be used as a signal to start drawing, but rather to
adjust self better to hit next vblank.

And that is something that already happens. However, Chromium also use
wl_surface.frame that is waited if a buffers are submitted earlier than
that arrives [1]. It's basically what mesa wayland egl does - whenever
eglSwapBuffers is called, it checks for the frame callback. If it's not
received yet, it waits until it's received and proceeds submitting
buffers.

However, I wonder if that is even necessary to do. It looks like a
redundant functionality given internal timer adjusts self according to
presentation times.

[1]
https://source.chromium.org/chromium/chromium/src/+/main:ui/ozone/platform/wayland/host/wayland_frame_manager.cc;l=352;drc=67172ba3828a038c491384620c3f854bd6d0ece9?q=wayland_frame_manager.cc&ss=chromium

-- 
Best Regards,
Maksim Sisov
* Usual work time - 08:00-16:00 (EEST).