Wayland presentation extension (video protocol) WIP after RFCv2

Daniel Stone daniel at fooishbar.org
Fri Apr 13 10:32:43 UTC 2018


On 13 April 2018 at 12:29, Michel Dänzer <michel at daenzer.net> wrote:
> On 2018-04-13 11:43 AM, Daniel Stone wrote:
>> On 13 April 2018 at 10:17, Michel Dänzer <michel at daenzer.net> wrote:
>>> Also, both higher-level APIs I know of which allow the application to
>>> specify a target timestamp for presentation (VDPAU and
>>> VK_GOOGLE_display_timing) use "not before" semantics. So, maybe the
>>> not_before flag can be dropped, and flags can be added later for
>>> different semantics, if a need for them ever materializes.
> Just to be clear, I meant that the default semantics should be "not before".

Understood. I think we need to fix/clarify the feedback side of
things, so that the app knows when exactly critical presentation
deadlines are, in order to synchronise its rendering loop. Once we
have that down properly, not-before for queuing makes sense.

>> ... that being said, VK_GOOGLE_display_timing's 'present margin' is
>> probably enough to cover these, rather than having to deal in absolute
>> timestamps.
> Not sure what you mean. presentMargin is the amount of time the
> application could have delayed the vkQueuePresentKHR call while still
> allowing to meet the desiredPresentTime as closely as possible. It
> doesn't affect that the image shouldn't be presented before
> desiredPresentTime.

Makes sense. No argument. :)


More information about the wayland-devel mailing list