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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to