Effects are given the interval between two consecutive frames. The main
flaw of this approach is that if the Compositor transitions from the idle
state to "active" state, i.e. when there is something to repaint,
effects may see a very large interval between the last painted frame and
the current. In order to address this issue, the Scene invalidates the
timer that is used to measure time between consecutive frames before the
Compositor is about to become idle.
While this works perfectly fine with Xinerama-style rendering, with per
screen rendering, determining whether the compositor is about to idle is
rather a tedious task mostly because a single output can't be used for
the test.
Furthermore, since the Compositor schedules pointless repaints just to
ensure that it's idle, it might take several attempts to figure out
whether the scene timer must be invalidated if you use (true) per screen
rendering.
Ideally, all effects should use a timeline helper that is aware of the
underlying render loop and its timings. However, this option is off the
table because it will involve a lot of work to implement it.
Alternative and much simpler option is to pass the expected presentation
time to effects rather than time between consecutive frames. This means
that effects are responsible for determining how much animation timelines
have to be advanced. Typically, an effect would have to store the
presentation timestamp provided in either prePaint{Screen,Window} and
use it in the subsequent prePaint{Screen,Window} call to estimate the
amount of time passed between the next and the last frames.
Unfortunately, this is an API incompatible change. However, it shouldn't
take a lot of work to port third-party binary effects, which don't use the
AnimationEffect class, to the new API. On the bright side, we no longer
need to be concerned about the Compositor getting idle.
We do still try to determine whether the Compositor is about to idle,
primarily, because the OpenGL render backend swaps buffers on present,
but that will change with the ongoing compositing timing rework.
Currently, if an X11 or Wayland window is damaged, we will schedule a
repaint. This results in some code duplication that this change intends
to get rid of.
Once the main surface has been unmapped, we are no longer interested in
any changes that indicate that the window quads cache should be discarded
This also fixes a bug where the scene holds a subsurface monitor object
even after the associated window has been destroyed.
AnimationEffect schedules repaints in postPaintWindow() and performs
cleanup in preScreenPaint(). With the X11-style rendering, this doesn't
have any issues, scheduled repaints will be reset during the next
compositing cycle.
But with per screen rendering, we might hit the following case
- Paint screen 0
- Reset scheduled repaints
- AnimationEffect::prePaintScreen(): update the timeline
- AnimationEffect::postPaintScreen(): schedule a repaint
- Paint screen 1
- Reset scheduled repaints
- AnimationEffect::prePaintScreen(): destroy the animation
- AnimationEffect::postPaintScreen(): no repaint is scheduled
- Return to the event loop
In this scenario, the repaint region scheduled by AnimationEffect will
be lost when compositing is performed on screen 1.
There is no any other way to fix this issue but maintain repaint regions
per each individual screen if per screen rendering is enabled.
BUG: 428439
Currently, we use glFinish() to ensure that stream consumers don't see
corrupted or rather incomplete buffers. This is a serious issue because
glFinish() not only prevents the gpu from processing new GL commands,
but it also blocks the compositor.
This change addresses the blocking issue by using native fences. With
the proposed change, after finishing recording a frame, a fence is
inserted in the command stream. When the native fence is signaled, the
pending pipewire buffer will be enqueued.
If the EGL_ANDROID_native_fence_sync extension is not supported, we'll
fall back to using glFinish().
Every time Platform::supportsQpaContext() is called, we go through the
list of supported extensions and perform a string comparison op. This is
not really cheap.
If the opaque area covers all the window's shape, it means that it's an
opaque window.
This is how GTK presents opacity right now, so we'll get to skip
rendering under GTK clients and other compatible ones.
Qt is still not emitting opacity.
This change replaces the remaining usages of the old connect syntax with
the new connect syntax.
Unfortunately, there are still places where we have to use SIGNAL() and
SLOT() macros, for example the stuff that deals with d-bus business.
Clazy was used to create this change. There were a few cases that needed
manual intervention, the majority of those cases were about resolving
ambiguity caused by overloaded signals.
Uses a setter and clear method pattern rather than having the code
repeated.
Instead of keeping a QPointer, now we are a QObject and we get notified
about destruction intention directly, so we can clear the pointer when
necessary.
Currently, we don't compute the clip region properly for some client-
side decorated applications, for example gedit, due to mixing several
separate coordinate spaces.
This change ensures that the window pixmap shape and the opaque region
are in the same coordinate space - the window pixmap coordinate.
In order to simplify mapping regions from the window pixmap coordinates
to the global screen coordinates, a new helper method was introduced in
the WindowPixmap class - mapToGlobal().
Summary:
Notify the driver about the parts of the screen that will be repainted.
In some cases this can be benefitial. This is especially useful on lima
and panfrost devices (e.g. pinephone, pinebook, pinebook pro).
Test Plan:
Tested on a pinebook pro with a late mesa version.
Basically I implemented it, then it didn't work and I fixed it.
Maybe next step we want to look into our damage algorithm.
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
The surface size is a logical size, which renders it unsuitable for
deciding whether the window pixmap needs to be discarded.
We need to discard window pixmaps when the buffer size changes. That
has a drawback though, discarding textures is kind of an overkill with
linux-dmabuf. However, fixing that would involve changes in kwayland
server that are far from being trivial.
BUG: 422459
The surface-to-buffer matrix provides a generic mechanism for mapping
things from the surface-local coordinate space to the buffer coordinate
space. If it changes, we know for sure that the texture coordinates
have to be re-computed.
We need a couple of connections to ensure that the window pixmap, the
window quad cache, and the window shape get discarded when the geometry
of the toplevel has been changed. Currently, those connections are
created with the receiver object being the scene. The problem is that
the associated wayland surface may outlive the toplevel and we don't
cleanup the connections after the scene window has been destroyed.
The fact that the connections don't get destroyed can lead to accessing
dangling pointers, which may result in a crash.
In order to ensure that the connections are broken automatically when
the scene window is destroyed, we need to ensure that the received
object is the scene window. That way, the connections will be destroyed
automatically.
The wp_viewporter compositor extension allows clients to crop and scale
their surfaces. It can be especially useful for applications wishing to
reduce their power consumption, e.g. video players, etc.
Given that there is no any direct relationship between the surface size
and the buffer size anymore, we have to use specialized helper methods
for converting coordinates from the surface-local space to buffer pixel
space and vice versa.
We currently deal with three distinct coordinate spaces - the window
pixmap coordinate space, the window coordinate space, and the buffer
pixel coordinate space.
This change introduces a couple of helper methods to make it easier
to map points from the window pixmap space to the other two spaces.
The main motivation behind the new helpers is to break the direct
relationship between the surface-local coordinates and buffer pixel
coordinates for wayland surfaces.
In order to generate window quads for a window, the scene needs a valid
WindowPixmap tree. If it's time to render the window, the scene will
build window quads for the contents, the server-side window decoration,
the drop-shadow and cache the resulting window quads. With this way of
generating window quads, we need the window pixmap tree to be valid,
or else no contents window quads will be generated.
While the window pixmap tree is guaranteed to be valid at the time of
generation of window quads for Wayland and X11 clients, this is not the
case for Xwayland clients.
When an Xwayland client is created, some time may pass between the
moment it's been created and the moment when a regular wayland surface
has been associated with the xwayland window. If the compositor decides
to render the Xwayland client in that short period of time, the window
quads cache won't have window quads cache.
In order to work around the weird asynchronous behavior of Xwayland
clients, this change makes the scene discard the window quad cache when
a new window pixmap has been created. This will ensure that the current
window quads are always in sync with the current window pixmap tree.
Sub-surface contribute to the window quads cache. So, we must re-build
it, if any sub-surface has been changed.
Differential Revision: https://phabricator.kde.org/D29131
No window quads are generated for sub-surfaces right now. This leads to
issues with effects that operate on window quads, e.g. magic lamp and
wobbly windows. Furthermore, the OpenGL scene needs window quads to
properly clip windows during the rendering process.
The best way to render sub-surfaces would be with a little help from a
scene graph. Contrary to GNOME, KDE hasn't developed any scene graph
implementation that we could use in kwin. As a short term solution, this
change adjusts the scene to generate window quads.
Window quads are generated as we traverse the current window pixmap tree
in the depth-first search manner. In order to match a list of quads with
a particular WindowPixmap, we assign an id to each quad.
BUG: 387313
FIXED-IN: 5.19.0
Differential Revision: https://phabricator.kde.org/D29131
We need to release the previous window pixmap if the new pixmap is
valid. However, it's currently the case only when the client has
attached either an fbo buffer or a wl_buffer. If an internal client
has attached a raster buffer, the previous window pixmap won't be
released.
In order to ensure that we're going to release the previous window
pixmaps no matter what type of buffer has been attached, this change
refactors WindowPixmap to use isValid() to verify that the new
window pixmap is valid.
Differential Revision: https://phabricator.kde.org/D29131
In order to generate window quads for sub-surfaces, we need a valid
window pixmap tree. The problem is that the window pixmap tree is
created too late in the rendering process. This change adjusts the
scene so it creates window pixmap trees before buildQuads().
Differential Revision: https://phabricator.kde.org/D29131
Summary:
The screenshot made on screens with scale factor were downscaled by their scale factor making them blurry.
It prevents taking screenshots of missing Hidpi related bugs showing the issues under Wayland.
This fix the case of a single screenshot, but not the rest:
Multiscreen screenshot downscales the screen using scale factor.
Spectacle rectangular selection screenshot is broken as soon as some scale factor different than 1 is used on any screen.
Test Plan:
Under Wayland with a scale factor on a screen, take a screenshot using spectacle.
The output image is not downscaled and has the same size as the screen resolution.
No other change to any other screenshot mode, or under X.
Reviewers: davidedmundson, #kwin
Reviewed By: davidedmundson, #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29010
The method paintSimpleScreen is responsible for redrawing the parts of
the back-buffer that need updating using the buffer_age extension.
The method fails to set correctly the damaged_region if, for some
reason, one frame needs a repaint of the whole screen. In this case
the backbuffer will request a full-screen repaint at some future
frame, so the dirty region will be extended to full-screen. However,
in this case the repaintRegion is not subtracted from the
damaged_region (as it is done for the non fullRepaints case below
--see the comment below--) and the damaged_region is reported to be the full
screen again. This causes all the subsequent frames to be reported
with a full screen damage, which causes some penalty, until
paintGenericScreen is invoked for some reason and then the damage gets
reset correctly.
We now set the correct damage and prevent falling into the fullRepaint
loop.
Summary:
We need to destroy the root WindowPixmap together with all of its
children; otherwise, buffers that are attached to subsurfaces will
not be released.
Test Plan:
weston-subsurfaces doesn't quit with an error message saying that
all buffers are held by the compositor.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28145
Summary:
This will save the copy of some objects, especially PaintData classes that are
not copy-on-write.
It also follows the practice on other parts of the system.
Test Plan: Running it right now
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28031
Summary:
When a window is being interactively resized, its contents may jump. The
reason why that happens is because KWin renders partially resized client
window. Composite extension spec says that a window will get a new pixmap
each time it is resized or mapped. This applies to the frame window, but
not to the client window itself. If the client window is resized,
off-screen storage for the frame window won't be reallocated. Therefore,
KWin may render partially resized client window if the client doesn't
attempt to be in sync with our rendering loop. Currently, the only way
to do that is to use extended frame counters, which are not supported by
KWin.
So, in order to fix visual artifacts during interactive resize, we need
somehow forcefully re-allocate off-screen storage for the frame window.
Unfortunately, Composite extension doesn't provide any request to do
that, so the only option we have is to resize the frame window.
BUG: 415839
FIXED-IN: 5.18.0
Reviewers: #kwin
Subscribers: davidedmundson, ngraham, alexde, fredrik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26914
Vlad Zahorodnii
Gabriel Souza Franco
Lewis Lakerink
Aleix Pol
Gang Wu
Adrien Faveraux
Méven Car
Jacopo De Simoi