[PATCH xserver v2 5/5] xwayland: use _XWAYLAND_ALLOW_COMMITS property

[Olivier Fourdan]

Hi Pekka,

----- Original Message -----
> here is an update on the Weston side:
> https://lists.freedesktop.org/archives/wayland-devel/2017-January/032712.html
> 
> The related Weston patches series has shrunk from 24 to 3 patches as
> lots of them have been merged. The stuff about _XWAYLAND_ALLOW_COMMITS
> is still pending.
> 
> Given the development on Weston side, would you demand implementing
> NET_WM_SYNC_REQUEST support in Weston before deciding whether to merge
> _XWAYLAND_ALLOW_COMMITS support in Xwayland, or is the rationale in the
> remaining Weston patches enough to justify it already?

I meant to reply your previous email but didn't quite finish it, sorry...

What I meant to say there is NET_WM_SYNC and _XWAYLAND_ALLOW_COMMITS are two different things and I don't think you can reach the same goals using NET_WM_SYNC_REQUEST.

The goal of NET_WM_SYNC is to make sure the window manager is not flooding the client with configure requests while the user resizes the window. Without NET_WM_SYNC, you can easily see the client window/repaint lagging behind when resizing even with an X11 compositor - That's quite different from what _XWAYLAND_ALLOW_COMMITS is meant for.

Not all apps use NET_WM_SYNC, actually few do (mostly gtk and qt based apps) when considering the large number of X11 apps available, so you cannot rely on NET_WM_SYNC being available, whereas having _XWAYLAND_ALLOW_COMMITS in Xwayland make it available for all X11 clients running on Wayland with a compositor taking advantage of it.

So, *IMHO* _XWAYLAND_ALLOW_COMMITS should not depend on weston implementing NET_WM_SYNC_REQUEST. Sorry if I caused some confusion.
 
> The window jumping I talked about no longer happens, due to reordering
> the patch series, but I believe that is just the race being won rather
> than lost most of the time and that the race which
> _XWAYLAND_ALLOW_COMMITS will remove still exists.

Cheers,
Olivier