[Mesa-dev] Playing with display timing -- VK_MESA_present_period

[Michel Dänzer]

On 2020-02-02 7:51 a.m., Keith Packard wrote:
>
> I spent some time over the last week experimenting with a different
> way of doing frame timing.
>
> Instead of specifying *when* a particular frame should be
> displayed, how about we specify how *long* a particular frame
> should be made visible to the user?
>
> This has a couple of advantages over the approach taken in
> GOOGLE_display_timing:
>
> 1. It provides information to the backend about frame timing a
> frame earlier.
>
> 2. Missing a frame can generate fewer artifacts.

I assume 2. refers to the case of a single late frame, where the next
frame hitting the original absolute target would result in a second
visible stutter. While writing
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234
, it occurred to me that although a relative target time may avoid
that second stutter, the audio stream needs to adapt to the visual
delay, likely producing audible artifacts instead? It's not obvious to
me that would be an overall win. (The only other way I can think of is
to re-synchronize later frames to the audio stream, but it's not clear
that this is possible without either producing visible stutter again,
or de-synced audio/video for a noticeable period of time)


P.S. Have you more formally proposed a Vulkan extension in the
meantime? If so, could you provide a reference to that here?

-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200624/ef5426f9/attachment.sig>