[RFC xserver 3/3] Xwayland: use _XWAYLAND_ALLOW_COMMITS property

[Pekka Paalanen]

On Mon, 5 Dec 2016 09:59:46 -0500 (EST)
Olivier Fourdan <ofourdan at redhat.com> wrote:

> Hi Pekka,
> 
> > [...]
> > Patches 1 and 2 OTOH would be ready for merging on my behalf.  
> 
> Yes, I think the two first patches are fine.

Hi Olivier,

thank you for the reviews!

> > Olivier asked about _NET_WM_SYNC_REQUEST - do you want me to fully
> > implement the basic sync protocol too before accepting this series?  
> 
> I was hoping/wondering if using _XWAYLAND_ALLOW_COMMITS could help
> the X11 window manager/X11 compositor to better sync the updates from
> the client with the refresh of the server side decorations (which
> includes drop shadows) to reduce the artefacts with server side
> decorations and drop shadows when resizing apps implementing the
> _NET_WM_SYNC_REQUEST protocol under Xwayland
> 
> But if anything, imho, it's up to the X11 window manager/X11
> compositor to use both mechanism when dealing with Xwayland, since
> the window manager/X11 compositor "knows" about both properties and
> when it's best to paint.

Right, however I wonder if the XWM always can reliably stop the commits
before the X11 client starts drawing the new size. I suppose with
interactive resizes using _NET_WM_MOVERESIZE and resizes initiated by
the XWM would be fine since the XWM knows there will be a resize before
telling the X11 client. But what if the client resizes spontaneously?

I assumed we would need some _NET_WM_SYNC_REQUEST support in Xwayland
always, but maybe we don't and doing it in XWM is enough?

> So FWIW, I don't think it's necessary to add _NET_WM_SYNC_REQUEST to
> Xwayland, when using _XWAYLAND_ALLOW_COMMITS. I'll play with mutter
> and _XWAYLAND_ALLOW_COMMITS to see how that goes :) 

Excellent!

> > [...]
> > I expect the property to be written only from the XWM. Should I
> > verify that somehow? Can I even identify the XWM here?  
> 
> I guess any client (or even user playing with xprop [1]) could
> add/change the property to any toplevel X11 window and Xwayland would
> stop committing the surfaces, but what would be the point of doing
> that?

Indeed. I suppose X11 is designed to shoot your own foot if you aim and
pull the trigger. ;-)

> Cheers,
> Olivier
> 
> [1] "xprop -id ... -format _XWAYLAND_ALLOW_COMMITS 32c -set
> _XWAYLAND_ALLOW_COMMITS 0" brings the update to a halt :)


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161205/d7ca5428/attachment.sig>