On Tue, 1 Aug 2017 20:53:02 +0200 Roman Gilg <subd...@gmail.com> wrote:
> -------- > Summary: > -------- > > (1) Deactivate queued presentation support for now (until we know which > kind of Wayland protocol to use for). > (2) Per window flipping when the pixmap flipping window region equals the > toplevel window. > (3) Listen on buffer release by Wayland compositor and only then allow > pixmap reuse. This is important but kind of controversial (see below). > (4) Support window pixmap flipping via Wayland sub-surfaces for windows, > that do _not_ region equal their toplevel window, i.e. windows which are > composited into the toplevel window with the Composite extension. Hi Roman, this is awesome work, and I am sad I have not had the time to properly dig into it. > ---------- > In detail: > ---------- > ad (3): > > In the Weston session I noticed extreme graphical artifacts in Neverball > (for a description of this app see below in Testing section). For sure this > was because of the reuse of pixmaps by the application after Xwayland > signaled that the pixmap is free to use again, but before the compositor > has released it. There were no artifacts in KWin, so I assume KWin just > quickly enough copies the pixel content and doesn't touch it again > afterwards. In the Weston case though the following happened: > > * Present gives pixmap A to Xwayland. > * A gets immediately committed and the flip is signaled as being complete > to Present (if we would wait for the frame callback, we would have an > implicit Vblank frame rate limit). > * Present signals PresentCompleteNotify to the app and the app then > directly starts drawing the next pixmap B, which is then again sent to > Xwayland. > * B gets immediately committed again and the flip is signaled es being > complete > * With B being flipped Present assumes, that A is directly reusable and > signals PresentCompleteNotify for B _and_ PresentIdleNotify for A. > * The app repaints into A or destroys it while still being read out by > Weston in some way. > > The solution is to listen for the buffer release signal by the Wayland > compositor and only on this signal send PresentIdleNotify to the app > instead of directly sending it on the next PresentCompleteNotify. To enable > that in the Rootless code path I did the following: Yes, listening to the buffer release signal is definitely the right thing to do from Wayland perspective. > ad (4): > > With the above I'm able to reliable flip pixmaps, when the flipping window > region equals the region of the toplevel window. This is according to my > experiments the case when not using any Composite clipping - see VLC in > Testing below for a good example. But tearing also happens in composite > windows, especially if a Wayland server wants to outscan a Xwayland buffer > to an overlay plane. > > For that I use a sub-surface for the flipping window. The flipping window's > pixmap buffer is flipped exclusively on the sub-surface, while the rest of > the window is committed to the main surface. I had problems with the right > alignment of the sub-surface and the disabling of input on the sub-surface, > but my research showed that these problems are inside KWin. In > comparison this works on Weston. The problem I have on Weston is a botched > up graphical depiction of the sub-surface content in general while it works > on KWin (see related question in Open Questions below). Please be aware that there are some open issues with respect to the sub-surface spec and implementations: https://phabricator.freedesktop.org/T7358 https://bugs.freedesktop.org/show_bug.cgi?id=94735 https://bugreports.qt.io/browse/QTBUG-52092 https://bugs.freedesktop.org/show_bug.cgi?id=101922 > * On Weston the sub-surface content is botched up completely. Is maybe the > support for desynchronized sub-surfaces in Weston not yet fully functional? What does "botched up completely" mean? A stride or a tiling format mismatch? A missing resolve pass? Can you share a screenshot or a photo? I would expect it to be something else than a sub-surface issue, if the pixel content is garbage or scrambled. If the content is just misplaced, frozen, not appearing, or has damage issues, that could be a sub-surface issue. Thanks, pq
pgpZ1xqw9uA7K.pgp
Description: OpenPGP digital signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel