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.
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.
