[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg-devel
Subject: Re: [RFC xserver 0/3] Allow XWM to control Xwayland commits
From: Owen Taylor <otaylor () fishsoup ! net>
Date: 2016-11-30 20:12:54
Message-ID: CA+0-Kjt7-tRqyzR0D6vinggYr72DYAniC04-3XrgNs77ZqMMRA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@gmail.com> wrote:
> On Fri, 25 Nov 2016 12:30:18 +0200
> Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> > On Fri, 25 Nov 2016 03:47:56 -0500 (EST)
> > Olivier Fourdan <ofourdan@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
> >
>
>
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic