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 <[email protected]> wrote: > On Fri, 25 Nov 2016 12:30:18 +0200 > Pekka Paalanen <[email protected]> wrote: > > > On Fri, 25 Nov 2016 03:47:56 -0500 (EST) > > Olivier Fourdan <[email protected]> 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 > > > >
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
