<div dir="ltr"><div><div><div>Hi Pekka,<br><br></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.<br><br></div>Regards,<br></div>Owen<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 8:47 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><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<br>
Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
<br>
> On Fri, 25 Nov 2016 03:47:56 -0500 (EST)<br>
> Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> wrote:<br>
><br>
> > Hi Pekka,<br>
> ><br>
> > > this is probably the first time I'm sending patches for the xserver, so<br>
> > > pointing out API misuse, coding style issues etc. would be appreciated. The<br>
> > > last patch also has some XXX comments with questions.<br>
> > ><br>
> > > The first patch, refactoring, is not absolutely necessary (anymore - I used<br>
> > > to<br>
> > > have a use for it while brewing this), but I think it makes things look<br>
> > > nicer.<br>
> > ><br>
> > > The fundamental problem is that Xwayland and the Wayland compositor (window<br>
> > > manager) are racing, particularly when windows are being mapped. This can<br>
> > > lead<br>
> > > to glitches. The specific glitch I bumped into is described at<br>
> > > <a href="https://phabricator.freedesktop.org/T7622" rel="noreferrer" target="_blank">https://phabricator.<wbr>freedesktop.org/T7622</a> .<br>
> > ><br>
> > > The proposed solution allows the WM to temporarily prohibit commits.<br>
> > ><br>
> > > It would be awkward for Weston to postpone mapping certain windows since it<br>
> > > would leak quite much Xwayland into the heart of the window manager. A<br>
> > > Wayland<br>
> > > compositor also cannot ignore commits, because Xwayland will wait for frame<br>
> > > callbacks until it commits again. To not get stuck, one would need to fire<br>
> > > frame callbacks outside of their normal path. It seems much simpler to just<br>
> > > control Xwayland's commits, which also ensures that the first commit will<br>
> > > carry<br>
> > > fully drawn window decorations too.<br>
> > ><br>
> > > This series is the Xwayland side of the fix to T7622. The Weston side is<br>
> > > still<br>
> > > brewing, but I was able to test that the Xwayland code works.<br>
> ><br>
> > I've taken a look at <a href="https://phabricator.freedesktop.org/T7622" rel="noreferrer" target="_blank">https://phabricator.<wbr>freedesktop.org/T7622</a> but I<br>
> > am not sure how that proposal would play with apps that implement the<br>
> > _NET_WM_SYNC protocol, using _NET_WM_SYNC_REQUEST and sync counters<br>
> > as described in EMWH [1]<br>
><br>
> Hi,<br>
><br>
> I have no idea. I don't know how that protocol works and Weston does<br>
> not use it. Yet.<br>
><br>
> > GNOME (mutter,gtk3) go a bit farther even and use an extended version<br>
> > of this protocol described by Owen [2].<br>
> ><br>
> > I suspect these make the de-syncronization with the Xwayland toplevel<br>
> > decorated by the X window manager even more visible under Wayland, as<br>
> > the repaint is scheduled according to the app content and not sync'ed<br>
> > with Xwayland and repaint of the shadows by the XWM.<br>
> ><br>
> > Would your proposal help there?<br>
><br>
> I would hope so, but given that I don't know how the sync protocol<br>
> works, I can't say. So far I'm just following the plan Daniel made.<br>
><br>
> From what Daniel wrote about the sync protocol in T7622, it sounds like<br>
> "my" proposal is the first step toward making the sync protocol really<br>
> successful.<br>
><br>
> I've been wondering though whether the client content sync<br>
> protocol should be implemented in the WM or could/should it be<br>
> implemented in Xwayland? Somehow it would feel natural to me, being a<br>
> foreigner to X11, that Xwayland would throttle its wl_surface.commits<br>
> based on both the client content sync protocol and the WM sync protocol<br>
> (this series). I don't think we would want to route every single commit<br>
> through the WM.<br>
><br>
><br>
> Thanks,<br>
> pq<br>
><br>
> > [1]<br>
> > <a href="https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472538288" rel="noreferrer" target="_blank">https://specifications.<wbr>freedesktop.org/wm-spec/wm-<wbr>spec-latest.html#<wbr>idm140200472538288</a><br>
> > [2] <a href="http://fishsoup.net/misc/wm-spec-synchronization.html" rel="noreferrer" target="_blank">http://fishsoup.net/misc/wm-<wbr>spec-synchronization.html</a><br>
<br>
Hi,<br>
<br>
having read the above two specs, it is very much not obvious how to<br>
connect all the dots. It needs experimenting.<br>
<br>
Would it be acceptable to build the knowledge of all these sync<br>
protocols into Xwayland server?<br>
<br>
The thing there is that Xwayland is issuing the wl_surface.commits, and<br>
having XWM to explicitly trigger all commits always seems like<br>
unnecessary overhead. However, Xwayland does not know when to commit if<br>
it doesn't understand the X11 sync protocols. Either every commit<br>
for every window has to roundtrip through XWM, or Xwayland needs to<br>
understand stuff. Or the third option, which I like the least, is to<br>
have the Wayland compositor special-case all surface from Xwayland and<br>
put them through a completely different and new code paths not shared<br>
with anything.<br>
<br>
The basic frame counter only throttles resizes, so that would be mostly<br>
between XWM and the X11 app. Xwayland could automatically stop<br>
committing when the counter indicates the app is busy reacting to a<br>
resize, and resume committing when the app catches up.<br>
<br>
The extended frame counter seems fairly straightforward at first hand<br>
to integrate as a commit prohibitor, like _XWAYLAND_ALLOW_COMMITS.<br>
<br>
I'm not sure if _NET_WM_FRAME_DRAWN should correspond to Wayland frame<br>
callbacks (which Xwayland could then handle on its own) or sent by XWM<br>
when it has drawn the decorations. The former would be more<br>
straightforward, the latter might allow using FRAME_DRAWN for<br>
triggering the commit but somehow I have a feeling it might not be a<br>
good idea...<br>
<br>
_NET_WM_FRAME_TIMINGS looks like something we could provide with the<br>
Presentation feedback protocol straight from Xwayland.<br>
<br>
Anyway, we have three different kinds of X11 apps:<br>
- no sync<br>
- basic sync<br>
- extended sync<br>
<br>
For the no-sync kind I think we still need something like my patch<br>
series. The other sync types would build on top, either by extending or<br>
replacing _XWAYLAND_ALLOW_COMMITS - or even just leaving it to XWM as a<br>
master switch of commits.<br>
<br>
Hence, at the moment, I believe this series would be a useful step<br>
forward, if the idea of the server inspecting properties is acceptable.<br>
<br>
Mind, I am mostly thinking this in Weston XWM terms, which draws the<br>
window decorations through X11 like a normal window manager. I'm not<br>
sure how things would change if the Wayland compositor drew the<br>
decorations directly, internally, as a part of composition, but I would<br>
hope it just means some steps in the sync protocols simply become<br>
no-ops.<br>
<br>
CC'd Owen in case he has opinions.<br>
<br>
<br>
Thanks,<br>
pq<br>
<br>
> > [3]<br>
> > <a href="https://bugzilla.gnome.org/show_bug.cgi?id=767212" rel="noreferrer" target="_blank">https://bugzilla.gnome.org/<wbr>show_bug.cgi?id=767212</a> [4]<br>
> > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=81275" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/<wbr>show_bug.cgi?id=81275</a><br>
><br>
<br>
</blockquote></div><br></div>