Updates to the Present and DRI3 extension specifications
davyaxel at free.fr
davyaxel at free.fr
Sun Oct 20 12:01:55 CEST 2013
> davyaxel at free.fr writes:
>
>> I have a few comments to share.
>
> Thanks!
>
>> In the context of XWayland, we may send the buffer to the
>> Wayland compositor (when client asks Present Option Async),
>> instead of doing a copy. I would like the specification to be
>> clarified to include that the buffer may be used for something
>> else than scanout and flipping.
>>
>> The same comment applies for the specification of the Present
>> options and the PresentCompleteNotify event.
>
> All of the Present options and capabilities are related to the physical
> scanout process; if there's another level of indirection between the
> client and that scanout engine, you'll have to ensure that the Async
> option is respected through that layer (or not advertised as a
> capability),
Ok, thanks for the precision, I had misunderstood some parts.
However I'm afraid that, reading the specifications, a client could think
that all options and events around Async or Flip happen only
when it is fullscreen.
In a Wayland world, the Wayland compositor won't release
any buffer sent, unless a new one has been sent (except for shm buffers).
So the behaviour will be similar to a flip, except the surface doesn't need
to be fullscreen.
Some Wayland backends could be able to use hardware overlays to do
an AsyncSwap of a small part of the screen.
That's why I suggest to add that a PresentCompleteModeFlip can happen
also when the window isn't fullscreen, and that PresentOptionAsync can
be useful too when the window isn't fullscreen.
> and that the other layer also reports accurate MSC and UST
> times for the scanout process.
>
> Any PresentCompleteNotify events must be delayed until the scanout
> process has started for the indicated frame.
>
For the moment it's not possible for us, but we are designing extension
that will make this possible. It shouldn't be an issue.
>
>
> Here's some clarifications to how idle fences are supposed to be used.
Thanks, it's clearer now for me.
Axel Davy
More information about the xorg-devel
mailing list