Second Feedback request for my GSoC project to improve Present support in Xwayland

[Pekka Paalanen]

On Tue, 1 Aug 2017 20:53:02 +0200
Roman Gilg <subdiff at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170811/20429f30/attachment.sig>