Some users reported performances issues after recent compositing
scheduling changes, in particular animations being laggy.
The issue is that sometimes it may take more than a vblank interval for
a buffer swap to complete. Previously, compositing was driven by a
timer and it wasn't synchronized to vblanks. If some frame is running
late, the compositor will just start painting a new frame, i.e. the
screen will be rendered triple buffered.
This change disables the swap events code path on Intel to restore the
previous behavior. Unfortunately, that may add an extra frame of latency.
The swap events code path can be enabled explicitly on Intel by setting
the KWIN_USE_INTEL_SWAP_EVENT environment variable to 1.
Warning messages are not the kind of messages that should be ignored,
they indicate that something is off or wrong.
Also, this makes triaging bugs easier as we no longer have to ask people
to run kwin with the QT_LOGGING_RULES environment variable set.
With the new compositing scheduling, we want the screen to be redrawn as
close as possible to the next vblank. Furthermore, compositing is no
longer driven by a timer. This change removes the NoSwapEncourage swap
strategy as it doesn't make sense now, in addition to that it just does
not work on Wayland.
If there is a pending frame, the RenderLoop will delay all schedule
repaint requests to the next vblank event. This means that the render
loop needs to be notified when a frame has been presented or failed.
At the moment, the RenderLoop is notified only about successfully
presented frames. If some frame fails, no repaints will be scheduled
on that output.
In order to make frame scheduling robust, the RenderLoop has to be
notified if a frame has failed.
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
We want to get notified when the next page flip occurs. The problem is
that kwin will avoid queueing a page flip if nothing has been changed on
the screen. From performance point of view, that is expected behavior,
but for frame scheduling and some wayland clients that create frame
callbacks to get notified about the next vblank, it's not suitable.
EGL for X and EGL for Wayland backends are quite different. The main
motivation behind this change is to prepare the EGL backends for
monitoring vblank events. Things work quite differently depending on
if the EGL backend renders onto a toplevel window or overlay window.
With the new compositing timing, we want to start compositing some time
later after a vsync event. This doesn't go along with the video sync
based method to synchronize buffer swaps with vblank.
Since practically all drivers nowadays provide support for the swap
control extensions (GLX_EXT_swap_control, GLX_SGI_swap_control, or
GLX_MESA_swap_control), it's safe to rely on them for the purpose of
synchronizing buffer swaps to vblank.
The compositing timing algorithm assumes that glXSwapBuffers() and
eglSwapBuffers() block. While this was true long time ago with NVIDIA
drivers, nowadays, it's not the case. The NVIDIA driver queues
several buffers in advance and if the application runs out of them,
it will block. With Mesa driver, swapping buffer was never blocking.
This change makes the render backends swap buffers right after ending
a compositing cycle. This may potentially block, but it shouldn't be
an issue with modern drivers. In case it gets proven, we can move
glXSwapBuffers() and eglSwapBuffers() in a separate thread.
Note that this change breaks the compositing timing algorithm, but
it's already sort of broken with Mesa drivers.
Plasma Mobile announced that they plan to drop support for Halium
devices, see the announcement blog post [1] for the reasons that led to
such a decision.
But just to summarize, here are some of the key points from the post:
* Some of our team members no longer have access to reference LG Nexus
5X device anymore
* After KDE Neon switched to using Ubuntu 20.04 we no longer are
updating the rootfs for halium devices
* After several important architecture changes in upstream KWin, the
hwcomposer backend might be broken and we have no way of verifying it
If the community members are interested in reviving the hwcomposer
backend,
* it pretty much needs rewrite/re-thinking given differences of hwc1
and hwc2 API for hwcomposer part of it, see also [2]
* It also needs removal of Android 5 based libhardware API as we don't
think code can be kept sane with 3 different levels of ifdefs
* This backend needs better way of fixing difference between
CAF/non-CAF devices then just recompiling with different headers,
maybe env vars?
* This backend does not support various things like transformation/
rotation etc, and is not exactly feature complete as the DRM backend
[1] https://www.plasma-mobile.org/2020/12/14/plasma-mobile-technical-debt.html
[2] 83f563c339
Since the Screens class is a convenience wrapper around AbstractOutput
objects that come from the Platform, it should not be platform-specific.
By dropping createScreens(), output-related code becomes simpler.
The default implementation of Screens::displaySize() returns the
bounding rectangle of all available outputs.
In case the Xrandr extension is unavailable, there will be a fake
output whose dimensions are the same as the dimensions of all screens
combined.
One of the annoying things about EGL headers is that they include
platform headers by default, e.g. on X11, it's Xlib.h, etc.
The problem with Xlib.h is that it uses the define compiler directive to
declare constants and those constants have very generic names, e.g.
'None', which typically conflict with enums, etc.
In order to work around bad things coming from Xlib.h, we include
fixx11.h file that contains some workarounds to redefine some Xlib's
types.
There's a flag or rather two flags (EGL_NO_PLATFORM_SPECIFIC_TYPES and
EGL_NO_X11) that are cross-vendor and they can be used to prevent EGL
headers from including platform specific headers, such as Xlib.h [1]
The benefit of setting those two flags is that you can simply include
EGL/egl.h or epoxy/egl.h and the world won't explode due to Xlib.h
MESA_EGL_NO_X11_HEADERS is set to support older versions of Mesa.
[1] https://github.com/KhronosGroup/EGL-Registry/pull/111
These signals can be useful if you want to know what output exactly has
been disabled or enabled.
The outputEnabled signal is emitted after the outputAdded signal, and
the outputDisabled signal is emitted before the outputRemoved signal.
