<div dir="ltr"><div><div><div>Hi Pekka, </div>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. </div>Regards, </div>Owen </div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Nov 28, 2016 at 8:47 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 25 Nov 2016 12:30:18 +0200 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > On Fri, 25 Nov 2016 03:47:56 -0500 (EST) > Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> 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 > > > <a href="https://phabricator.freedesktop.org/T7622" rel="noreferrer" target="_blank">https://phabricator.freedesktop.org/T7622</a> . > > > > > > 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 <a href="https://phabricator.freedesktop.org/T7622" rel="noreferrer" target="_blank">https://phabricator.freedesktop.org/T7622</a> 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] > > <a href="https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472538288" rel="noreferrer" target="_blank">https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472538288</a> > > [2] <a href="http://fishsoup.net/misc/wm-spec-synchronization.html" rel="noreferrer" target="_blank">http://fishsoup.net/misc/wm-spec-synchronization.html</a> 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] > > <a href="https://bugzilla.gnome.org/show_bug.cgi?id=767212" rel="noreferrer" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=767212</a> [4] > > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=81275" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=81275</a> > </blockquote></div> </div>