* 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
The ImageCursorSource used to be primarily a porting aid. That is, if we
couldn't port some code to SurfaceCursorSource or ShapeCursorSource, the
ImageCursorSource was used in interim. Now, all parts of kwin have been
ported to ShapeCursorSource and SurfaceCursorSource, so the image cursor
source can be dropped.
SurfaceInterface::scaleOverride() doesn't scale the bufferScale, so if the
scale override is 2, but the buffer scale specified by the client is 1,
bufferScale() will return 1.
Xwayland cursor surface implicitly relied on this behavior.
Porting cursor to SurfaceItem changed that. Now cursor surfaces honor
the scale override, which makes Xwayland cursors too small.
In order to properly fix, plasma has to scale Xcursor.size in xrdb. The
problem is that plasma also sets XCURSOR_THEME and XCURSOR_SIZE envvars
that take precedence. Plasma must stop setting those envvars, but it's
doable only with Qt 6.5, which got MouseCursorTheme and MouseCursorSize
hints in QPlatformTheme.
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.
