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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel