On 2021/06/23 17:04, Michel Dänzer wrote: > On 2021-06-22 9:57 a.m., Pekka Paalanen wrote: >> On Tue, 22 Jun 2021 13:02:59 +0900 >> Esaki Tomohito <e...@igel.co.jp> wrote: >> >>> Hi, Thomas >>> Thank you for reply. >>> >>> On 2021/06/21 16:10, Thomas Zimmermann wrote: >>>> Hi >>>> >>>> Am 21.06.21 um 08:27 schrieb Tomohito Esaki: >>>>> Virtual DRM splits the overlay planes of a display controller into >>>>> multiple >>>>> virtual devices to allow each plane to be accessed by each process. >>>>> >>>>> This makes it possible to overlay images output from multiple >>>>> processes on a >>>>> display. For example, one process displays the camera image without >>>>> compositor >>>>> while another process overlays the UI. >>>> >>>> I briefly looked over your patches. I didn't understand how this is >>>> different to the functionality of a compositor? Shouldn't this be solved >>>> in userspace? >>> >>> I think when latency is important (e.g., AR, VR, for displaying camera >>> images in IVI systems), there may be use cases where the compositor >>> cannot be used. >> >> Hi, >> >>> Normally, when the image is passed through the compositor, it is >>> displayed after 2 VSYNC at most, because the compositor combines the >>> image with VSYNC synchronization. >> >> This is not a universal fact. You can write a Wayland compositor that >> consistently reaches app-to-screen latency of less than one monitor >> refresh cycle, while also using KMS planes. >> >> I believe Weston succeeds in this already if you write the Wayland >> application accordingly. > > For a specific example, > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620 allows > app-to-screen latency as low as ~6 ms (including a fixed 2 ms buffer to avoid > skipped frames). mutter doesn't use KMS planes yet, but if anything I'd > expect that to help rather than hurt for latency (if the compositor doesn't > need to draw anything).
Thank you for providing specific examples. Best regards Esaki
