* 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
Floating point arithmetic and/or the use of GL_LINEAR in the pipeline,
may result in visual glitches due to rounding (errors). As a short-term
fix until a proper (more involved) solution is in place for Plasma 6,
pad the damage slightly in all directions to alleviate those effects.
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.
The order in which windows are painted is computed dynamically every
frame. On the other hand, with the introduction of items, it's desired
to avoid doing that so repaints can be scheduled as needed. The
unification also opens the possibilities for more rendering related
refactors to make the code nicer and more reusable.
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.
kwineffects.h is included in many files and not everyone needs the
RenderTarget and RenderViewport, so forward declare them to reduce the
amount of parsing work for the compiler.
The only purpose ScreenPaintData had was to pass around a copy of the viewport
projection matrix and the effectscreen, which can be handled in a simpler
way separately.
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
If a window is made ready for painting with some delay, the item won't
schedule an update. To fix that, sync the item visibility state with
Window::readyForPainting(). When the item visibility changes, a repaint
will be scheduled.
BUG: 464955
While direct scanout happens, the damage of the SurfaceItem is reset, which
can cause the OpenGL texture to not be updated once direct scanout ends,
and leave the texture outdated until the surface is damaged again.
In order to fix that, make sure the texture is always fully updated after
the SurfaceItem has been used in direct scanout.
The main motivation behind this change is to share rendering code
between windows and the cursor, specifically the Item class which
requires a Scene.
Note that Scene subclasses are responsible for issuing
ItemRenderer::renderItem() calls. The main reason for that is the
current architecture of the effects system, specifically we need to call
some effects hooks before and after painting a window.
