QVector::count()'s return type is qsizetype. On a 64 bit platform, it's
equivalent to qint64, so "%d" does not suffice.
There are two ways to fix it: use PRIdQSIZETYPE or switch to the stream
operator. Since the warning format is not complex, this takes the latter
approach.
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.
This makes the behavior of the virtual backend more consistent with
wayland, x11, and drm backends. However, the main advantage is that it's
more nicer to memfd fallback code path in screencasting plugin.
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.
The differences between windowed and host flavors of the X11 backend
have become too big, so let's split EglOnXBackend to avoid abstracting
something that makes little sense.
It helps to express the ownership of the pipe fd in ScreenShotSinkPipe2
better.
ScreenShotSinkPipe2 is not made to take a FileDescriptor too because
it's complicated by CaptureInteractive().
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.
At the moment, the buffers for wsi are allocated implicitly by the EGL
implementation, which is fine for "normal" use cases. But we start
hitting the ceiling the moment we need to something more advanced. For
example the EGL backend creates a dummy fbo object wrapping the default
framebuffer, meaning that we cannot pass it to qtquick (because it can
use its own opengl context).
Another reason for using explicit buffers is that it lets us to clean up
some output related abstractions.
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
Qt would need to allocate fewer "tainted" data objects, and using the
same engine both in effects and in kwin is vital for features such as
QML based effects.
