If a repaint is scheduled in the prePaintScreen() function, we want
it to be applied in the next frame, not the current one.
Currently, it doesn't work like this because prePaintScreen() runs first
then the Compositor gathers repaints and resets them.
This is important to qtquick effects that use qtquick3d as some items in
qtquick3d schedule repaints for the next frame after synchronizing, i.e.
in OffscreenQuickView::update() which is called in prePaintScreen() by
QuickSceneEffect.
On Wayland, options don't influence compositing as on X11. For example,
kwin cannot easily switch between compositing modes, etc.
One can still force kwin_wayland to reinitialize compositing by using
the dbus api.
It makes little sense to destroy effects if the animation speed changes.
The effects are written with the assumption that the animation time can
change and therefore they handle this case in reconfigure().
With the current vision for how output backends work, the compositor
should take up more responsibilities. There are a few good reasons: some
things just don't make sense to be in backends, to allow sharing code
across backends easier, etc. On the other hand, we have X11, with its
own ways of doing things which are not always compatible with what we
want to do on Wayland.
The goal of this patch is to start splitting the compositor into
platform specific counterparts, with potentially moving X11 compositing
in kwin_x11. The main benefit of this is that we will be able to
push forward with wayland things more freely. Ideally it would be great
if we could make kwin_x11 have its own low level compositing code paths
that are nicely encapsulated in that executable and don't leak into
libkwin abstractions.
The biggest drawback of this approach is that there is going to be some
code duplication between x11 and wayland compositing code paths. But I
expect it to be the case only for a short term until we start landing
more abstractions in kwin_wayland, e.g. render devices, proper output
layer support, etc.
Currently, the Workspace is responsible for rerouting
X11Window::blockingCompositingChanged to
X11Compositor::updateClientCompositingBlocking(). It has a few issues:
if the client is initially blocking compositing, it's not going to work
as expected. The second issue is that it creates a coupling between
platform specific compositor implementation and generic Workspace. It's
a blocker for moving X11Compositor to kwin_x11 executable, etc.
If somebody else claims the compositing selection, we definitely do not
want to stop compositing. It will also help with encapsulating
X11-specific code and splitting it out in the future.
Config loading is split in two groups: loading compositing config and
loading the rest. They are loaded separately at different times. Some
options are loaded in the Options constructor, some are loaded when compositing
starts, some are loaded when the Workspace is created. It's not easy to
keep track of what loads what and when.
This change simplifies option handling by loading all options in bulk
and decouples Options from OutputBackend and GLPlatform to ensure that
it can safely load options before kwin is fully operational.
This commit also drops most of the code around checks for direct rendering. If
direct rendering isn't supported, creating the OpenGL context will now simply fail,
achieving the same effect
Currently when we move the mouse the one render loop triggers a repaint.
When the cursor layer needs a new update we end up in the compositor
repainting the main content.
Even though painting should mostly no-op it still goes through all
existing items and effects to collect damage, still potentially making
the GL context current which could stall. A waste when we know we
haven't got anything to do. It's enough to cause noticable mouse lag on
some hardware.
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
Don't fall back into other composition systems if KWIN_COMPOSE is
explicitly set. In such case, just exit().
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
With the dmabuf multi-gpu path, a buffer is imported to the secondary GPU
and presented directly, but importing a buffer that's usable for scanout
is not possible that way on most hardware. To prevent CPU copy from being
needed in those cases, this commit introduces a fallback where the buffer
is imported for rendering only, and then copied to a local buffer that's
presented on the screen.
CCBUG: 452219
CCBUG: 465809
Currently, managed and override-redirect windows are split in two types:
X11Window and Unmanaged. While looking at it strictly from type
perspective, this is great. But it creates other problems, e.g. we need
to put shared X11-specific code in the base Window class or mess with
"base" classes.
As an alternative solution, this change merges the Unmanaged class into
the X11Window class and disables some functionality based on the value
of isUnmanaged().
X11Window::manage() is used to create a managed Window. X11Window::track()
is used to create an unmanaged Window.
Currently windows are scattered in a few separate lists. If you need to
go through the windows, you have to do it piece by piece. On the other
hand, with the overhaul of window types, we've started converging
towards one universal type: Window. Keeping windows in the separate
buckets goes against this design.
Workspace::stackingOrder() already contains all windows. This change
repurposes Workspace::allClientList() from a list of "normal" windows to
all windows, i.e. Workspace::windows(), to be consistent.
There's one API change though. Scripting API will expose other window
types too. This is an intentional change so scripted effects could
operate with all windows. It also matches the current behavior observed
in libkwineffects, which exposes all windows as well.
Currently Deleted are destroyed with a delay to avoid dangling pointers
within the middle of painting.
On the other hand, it's reasonable to require not to delete windows when
kwin starts painting the screen.
Over the years, we refactored how deleted windows. They are always
unreferenced after finishing the current frame. So it should be fine to
destroy Deleted immediately now.
Instead of calling effects->renderTargetRect() and effects->renderTargetScale(),
pass the actually used render target and viewport in all the necessary methods.
This ensures that if an effect renders a screen with a modified scale or
projection matrix, the modified values get used instead of the "global" ones
Instead of best-guessing, at BGR (which in retrospect was a bad guess),
offer whatever resembles most the internal representation. This way the
frame gets to be least treated as it goes into the client.
The cursor scene contains the contents of the cursor. It contains a
CursorItem. The CursorItem either creates a SurfaceItem or an ImageItem
based on the currently attached CursorSource.
The cursor item is rendered by the cursor scene. For now, wherever the
cursor must be rendered, a dummy scene delegate is constructed. It's not
nice but it's a pretty cheap operation. There's a lot of potential for
clean up by moving cursor layer handling from output backends to
compositor. The main reason why there are no persistent scene views is
that it's just easier than tracking when they are actually used, e.g.
after switching between hw and sw cursor.
The software cursor fallback is a bit tricky case. It made to work by
constructing a scratch fbo. The cursor scene is rendered in the scratch
fbo, which is then rendered on the screen. Similar to the case above,
there's space for improvements, but I don't think it has to block the
effort for reusing Items to render the cursor.
This kind of code doesn't belong in the SceneOpenGL. Moving it to the
Compositor class allows us to make the Scene class less central and
permit running with more than one scene, e.g. one for the workspace and
the other one for the cursor, etc.
Currently, output backends track the cursor behind the scenes. This
results in some amount of code duplication, for example the handling of
hidden cursors, every backend handles in its own unique way, some don't
do it correctly. Another issue is that output backend interact with
other components behind the back. This can be a problem for tasks such
as backing the cursor with an output layer.
This change introduces explicit output cursor manipulation APIs in the
Output class. There's a good chance that it's going to be revised more
in the future as part of streamlining output layer manipulation apis.
With the proposed changes, the workspace would need to call
Output::setCursor() or Output::moveCursor() to set/unset or move the
cursor, respectively.
OutputBackend has a concept of readiness. When the host compositor goes
down, the OutputBackend will be marked as not ready, and when it
reappears, the output backend will be marked ready again.
On the other hand, host compositor going down is a niche case, it's not
something that often happens and it's hard to justify adding more moving
parts to the startup code. It's easier to call initialize() and check
whether it fails rather than call initialize() and then monitor isReady.
Therefore, this change drops OutputBackend::isReady() to make startup
simpler.
Vlad Zahorodnii
Xaver Hugl
David Edmundson
Laurent Montel
Aleix Pol Gonzalez
Aleix Pol