> davya...@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 _______________________________________________ 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