[PATCH 14/19] present: Add window flip mode

[Roman Gilg]

On Fri, Feb 2, 2018 at 5:11 PM, Michel Dänzer <michel at daenzer.net> wrote:
> Taking a step back, do we even need to keep around the original pixmap
> and unflip to it at all? I had a chat on IRC about this with Keith a
> while ago, see the attached log excerpt.
>
> Keith's main concern is that the presenting client could be able to
> read/write the window pixmap's contents behind the X server's back. I
> understand this concern at least somewhat in the case of per-screen
> flips, because the screen pixmap can be used for completely different
> windows after flipping.
>
> But this seems irrelevant for per-window flips. In this case, the window
> pixmap isn't used for anything else after flipping, so having direct
> access to the pixmap doesn't allow the client to do anything it couldn't
> do anyway using the X11 protocol. (There might be exceptions to this if
> the window wasn't created by the presenting client, and the Security
> extension comes into play. But that would be a rather exotic scenario,
> so I don't think we need to consider it here.)

An unflip might happen at any time when the window is reconfigured and
the check_flip_window function returns false. Then we need again a
pixmap for the window to paint to.

> Unfortunately, I've come to realize that this doesn't work correctly in
> all cases. Consider this scenario:
>
> A client does one or more presentations to a window, which can be
> executed as a flip. At some point it stops doing presentations, and
> instead uses other X11 requests to update the window contents.
>
> With the implementation in this patch, the latter updates will only
> affect the original window pixmap, not the flip pixmap, so they won't be
> visible to the Wayland compositor and its output (until an unflip to the
> original window pixmap is triggered for some reason).

This is indeed a problematic corner case. But do such clients really
exist? A client using one of its child windows to flip pixmaps on,
most likely with DRI, and then at some point deciding to paint to the
current window pixmap of the same child window directly instead seems
kind of odd.