D29250: [wayland] Enable synchronized resizing for Xwayland clients

[Vlad Zahorodnii]

zzag created this revision.
zzag added a reviewer: KWin.
Herald added a project: KWin.
Herald added a subscriber: kwin.
zzag requested review of this revision.

REVISION SUMMARY
  Currently, synchronized resizing for X11 clients on Wayland is disabled
  because updateXTime() is implemented only for the standalone X11 platform.
  We cannot make roundtrips to Xwayland to query its current X11 time stamp
  because we may end up in a dead lock. On the other hand, we cannot query
  the time stamp asynchronously because doing so may introduce a lot of
  regressions. The best option what we've got is to guess Xwayland's X11
  time stamp. Fortunately, we know that Xwayland uses the system monotonic
  time for time stamps. So, we can query the monotonic time in
  updateXTime(). Note that when KWin is not running as a Wayland window
  manager, it still does roundtrips to the X server.
  
  Unfortunately, providing an implementation for updateXTime() and moving
  the sync alarm filter to the toplevel directory is not enough. The latest
  stable release of Xwayland (1.20.8) doesn't use multiple window buffers.
  So, it's quite possible that an X11 client may update the buffer after
  it's been committed and not released by the compositor yet. In our case,
  when the frame window is resized, the buffer will be destroyed. This in
  its turn _may_ render the previous and the current window pixmap invalid.
  
  There are several ways to work around the window pixmap issue. (a) Just
  ignore it. We probably don't want to do it because visual artifacts
  caused by invalid window pixmaps are relatively severe. (b) Scratch the
  contents of the buffer when the surface is committed rather than late in
  the rendering process. The main drawback of this approach is that it
  means we need to perform unnecessary copy operations if the client has
  attached more than one shm buffer during a vblank interval. (c) Enable
  synchronize resizing for Xwayland that uses multiple window buffers.
  
  Even with all of its drawbacks, the option (b) is quite tempting since
  it makes window pixmap management a little bit robust. However, it'd
  require changes in the buffer management code, which I personally would
  like to avoid. So, instead, I've picked the option (c). With the addition
  of multiple window buffers in Xwayland 1.21, there should not be any
  severe visual artifacts during a resize operation and we don't have to
  tweak our buffer management code.
  
  In order to disable synchronized resizing for Xwayland clients, this
  patch series has introduced a new client class - XwaylandClient. The new
  class is used to represent X11 clients that are connected to Xwayland.
  The X11Client class is used to represent X11 clients when KWin runs as
  not a Wayland window manager. The new class also allows to specialize
  some code that is irrelevant to X11Client.

TEST PLAN
  Built xserver from git, resized an X11 client that supports
  _NET_WM_SYNC_REQUEST.

REPOSITORY
  R108 KWin

BRANCH
  xwayland-synchronized-resize

REVISION DETAIL
  https://phabricator.kde.org/D29250

AFFECTED FILES
  CMakeLists.txt
  platform.cpp
  platform.h
  plugins/platforms/x11/standalone/CMakeLists.txt
  plugins/platforms/x11/standalone/sync_filter.cpp
  plugins/platforms/x11/standalone/sync_filter.h
  plugins/platforms/x11/standalone/x11_platform.cpp
  plugins/platforms/x11/standalone/x11_platform.h
  syncalarmx11filter.cpp
  syncalarmx11filter.h
  workspace.cpp
  workspace.h
  x11client.cpp
  x11client.h
  xwaylandclient.cpp
  xwaylandclient.h

To: zzag, #kwin
Cc: kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwin/attachments/20200428/1578211e/attachment.html>