[RFC xserver 0/3] Allow XWM to control Xwayland commits

[Pekka Paalanen]

On Fri, 25 Nov 2016 03:47:56 -0500 (EST)
Olivier Fourdan <ofourdan at redhat.com> wrote:

> Hi Pekka,
> 
> > this is probably the first time I'm sending patches for the xserver, so
> > pointing out API misuse, coding style issues etc. would be appreciated. The
> > last patch also has some XXX comments with questions.
> > 
> > The first patch, refactoring, is not absolutely necessary (anymore - I used
> > to
> > have a use for it while brewing this), but I think it makes things look
> > nicer.
> > 
> > The fundamental problem is that Xwayland and the Wayland compositor (window
> > manager) are racing, particularly when windows are being mapped. This can
> > lead
> > to glitches. The specific glitch I bumped into is described at
> > https://phabricator.freedesktop.org/T7622 .
> > 
> > The proposed solution allows the WM to temporarily prohibit commits.
> > 
> > It would be awkward for Weston to postpone mapping certain windows since it
> > would leak quite much Xwayland into the heart of the window manager. A
> > Wayland
> > compositor also cannot ignore commits, because Xwayland will wait for frame
> > callbacks until it commits again. To not get stuck, one would need to fire
> > frame callbacks outside of their normal path. It seems much simpler to just
> > control Xwayland's commits, which also ensures that the first commit will
> > carry
> > fully drawn window decorations too.
> > 
> > This series is the Xwayland side of the fix to T7622. The Weston side is
> > still
> > brewing, but I was able to test that the Xwayland code works.  
> 
> I've taken a look at https://phabricator.freedesktop.org/T7622 but I
> am not sure how that proposal would play with apps that implement the
> _NET_WM_SYNC protocol, using _NET_WM_SYNC_REQUEST and sync counters
> as described in EMWH [1]

Hi,

I have no idea. I don't know how that protocol works and Weston does
not use it. Yet.

> GNOME (mutter,gtk3) go a bit farther even and use an extended version
> of this protocol described by Owen [2].
> 
> I suspect these make the de-syncronization with the Xwayland toplevel
> decorated by the X window manager even more visible under Wayland, as
> the repaint is scheduled according to the app content and not sync'ed
> with Xwayland and repaint of the shadows by the XWM.
> 
> Would your proposal help there? 

I would hope so, but given that I don't know how the sync protocol
works, I can't say. So far I'm just following the plan Daniel made.

From what Daniel wrote about the sync protocol in T7622, it sounds like
"my" proposal is the first step toward making the sync protocol really
successful.

I've been wondering though whether the client content sync
protocol should be implemented in the WM or could/should it be
implemented in Xwayland? Somehow it would feel natural to me, being a
foreigner to X11, that Xwayland would throttle its wl_surface.commits
based on both the client content sync protocol and the WM sync protocol
(this series). I don't think we would want to route every single commit
through the WM.


Thanks,
pq

> [1]
> https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472538288
> [2] http://fishsoup.net/misc/wm-spec-synchronization.html [3]
> https://bugzilla.gnome.org/show_bug.cgi?id=767212 [4]
> https://bugs.freedesktop.org/show_bug.cgi?id=81275

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161125/c2114780/attachment.sig>