Updates to the Present and DRI3 extension specifications

[davyaxel at free.fr]

Here are some comments to complete my last message.


>> 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.
I think there may be a problem here,
since we have an additional layer.

I assume MSC and UST times in the Present Extension are
the ones at which the frame hit the screen.

Given this, there may be issues if a client wants to cap to
screen refresh.
Imagine the screen is 60 hz. A framebuffer X is displayed on the screen.
We send to the Wayland compositor the buffer.
It can have already drawn next frame (framebuffer Y).
When framebuffer Y hit the screen, next frame is redrawn and we use
the recently sent buffer. A frame event is sent with the time at which
the buffer was used (but we wouldn't use it for Present). After some
time, framebuffer Y is replaced with the new framebuffer, and here
a new event would be sent to inform the client the buffer
hit the screen (and we would use it for Present). Ideally at that time,
the client would have already sent a new buffer for next frame,
so the repainting would use this already sent buffer.

Thus, to have a client refreshing at 60 fps, it shouldn't wait
the PresentCompleteNotify before sending a new pixmap
for next frame. To prevent issues, I suggest this to be
clarified in the specification. 
("a client can send a new PresentPixmap request, even if
the last one hasn't completed yet. It won't cancel the last
request, but the PresentCompleteNotify for the older pixmap
may have the mode PresentCompleteModeSkip")

Thanks,

Axel Davy