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

[Owen Taylor]

Hi Pekka,

I don't have a lot of of commentary to add here. Certainly getting the
frame-sync protocols right does require integration between Xwayland and
the compositing manager. I don't think there's that much virtue in spending
time on the extended version of the sync protocol and
_NET_WM_FRAME_TIMINGS, because, to my knowledge, those are implemented only
by GTK+ 3, and most GTK+ 3 apps will be running as native Wayland apps. On
the other hand, gtk2 and qt4 X clients will be around to exercise the basic
version of the protocol for the forseeable future.

Regards,
Owen

On Mon, Nov 28, 2016 at 8:47 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Fri, 25 Nov 2016 12:30:18 +0200
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> > 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
>
> Hi,
>
> having read the above two specs, it is very much not obvious how to
> connect all the dots. It needs experimenting.
>
> Would it be acceptable to build the knowledge of all these sync
> protocols into Xwayland server?
>
> The thing there is that Xwayland is issuing the wl_surface.commits, and
> having XWM to explicitly trigger all commits always seems like
> unnecessary overhead. However, Xwayland does not know when to commit if
> it doesn't understand the X11 sync protocols. Either every commit
> for every window has to roundtrip through XWM, or Xwayland needs to
> understand stuff. Or the third option, which I like the least, is to
> have the Wayland compositor special-case all surface from Xwayland and
> put them through a completely different and new code paths not shared
> with anything.
>
> The basic frame counter only throttles resizes, so that would be mostly
> between XWM and the X11 app. Xwayland could automatically stop
> committing when the counter indicates the app is busy reacting to a
> resize, and resume committing when the app catches up.
>
> The extended frame counter seems fairly straightforward at first hand
> to integrate as a commit prohibitor, like _XWAYLAND_ALLOW_COMMITS.
>
> I'm not sure if _NET_WM_FRAME_DRAWN should correspond to Wayland frame
> callbacks (which Xwayland could then handle on its own) or sent by XWM
> when it has drawn the decorations. The former would be more
> straightforward, the latter might allow using FRAME_DRAWN for
> triggering the commit but somehow I have a feeling it might not be a
> good idea...
>
> _NET_WM_FRAME_TIMINGS looks like something we could provide with the
> Presentation feedback protocol straight from Xwayland.
>
> Anyway, we have three different kinds of X11 apps:
> - no sync
> - basic sync
> - extended sync
>
> For the no-sync kind I think we still need something like my patch
> series. The other sync types would build on top, either by extending or
> replacing _XWAYLAND_ALLOW_COMMITS - or even just leaving it to XWM as a
> master switch of commits.
>
> Hence, at the moment, I believe this series would be a useful step
> forward, if the idea of the server inspecting properties is acceptable.
>
> Mind, I am mostly thinking this in Weston XWM terms, which draws the
> window decorations through X11 like a normal window manager. I'm not
> sure how things would change if the Wayland compositor drew the
> decorations directly, internally, as a part of composition, but I would
> hope it just means some steps in the sync protocols simply become
> no-ops.
>
> CC'd Owen in case he has opinions.
>
>
> Thanks,
> pq
>
> > > [3]
> > > https://bugzilla.gnome.org/show_bug.cgi?id=767212 [4]
> > > https://bugs.freedesktop.org/show_bug.cgi?id=81275
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161130/39a74547/attachment.html>