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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
