Summary:
First step for loading the compositor Scenes through plugins. The general
idea is that we currently needlessly pull in all the Scenes although only
one will be used.
E.g. on X11 we pull in QPainter, although they are not compatible. On
Wayland we pull in XRender although they are not compatible.
Furthermore our current Scene creation strategy is not really fault
tolerant and can create situations where we don't get a compositor. E.g
on fbdev backend the default settings won't work as it does not support
OpenGL.
Long term I want to tackle those conceptional problems together:
we try to load all plugins supported by the current platform till we have
a scene which works. Thus on Wayland we don't end up in a situation where
we don't have a working compositor because the configuration is bad.
To make this possible the switch statement in the Scene needs to go and
needs to be replaced by a for loop iterating over all the available
scenes on the platform. If we go there it makes sense to replace it
directly with a plugin based approach.
So this is a change which tackles the problem by first introducing the
plugin loading. The xrender based scene (as it's the most simple one)
is moved into a plugin. It is first tried to find a scene plugin and only
if there is none the existing code is used.
Test Plan: Tested all scenes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7232
Summary:
KWin::displayWidth and KWin::displayHeight are bound to X11 which
doesn't make much sense on X11. In addition KWin internally knows
the overall display dimensions through the Screens singleton class.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D1798
Summary:
The overlay window is only needed for the X11 based compositors. Given
that it is better suited in the X11 platform. Unfortunately it is not
possible to completely move it into the platform plugin as it is still
referenced in KWin core (e.g. SceneXRender). Due to that the
OverlayWindow in KWin core is turned into a pure virtual class with the
implementation being moved into the plugin.
The platform API gains a new virtual factory method which is only
implemented in the X11 platform.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7193
Summary:
So far EffectsHandlerImpl directly accessed SceneXrender::bufferPicture
through a dynamic cast. If in future the XRender based compositor should
be moved into a plugin we cannot access it through a dynamic cast.
To solve this problem the bufferPicture method is moved into Scene as
a virtual method returning a sane default value.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7207
This change is needed for Wayland screen recording apps to work
correctly. With this change the cursor is actually visible using GBM
buffer passing protocol.
Previously OpenGL backend did not support software cursor. If launching
in DRM/OpenGL mode with flicked on software cursor it only rendered
scene, but not the cursor image.
Differential Revision: https://phabricator.kde.org/D6186
Summary:
Using a static XRenderPicture results in a crash on exit as for cleanup
the already destroyed xcb_connection_t* is required.
This change ensures that the static XRenderPicture gets destroyed in the
static cleanup handler for SceneXRender::Window.
CCBUG: 363251
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1733
Summary:
It can be null even after updateTextTexture() if there is not text
to generate the texture from:
if (m_effectFrame->text().isEmpty())
return;
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1347
It didn't get adjusted for Xwayland, so probably doesn't work any more.
The rendering mode seems not very useful if honest and it's better to
use the QPainter backend.
The DecorationShadow on XRender is implemented by creating the
required QPixmaps in ::prepareBackend. That way the rendering
infrastructure can be shared with the window based shadows.
BUG: 342758
REVIEW: 122009
Move the buffer-swap-pending state from the compositing backends to
the Compositor class. The Compositor is the only class that needs to
access the state, and this way it to do it without calling through
a chain of virtual functions. This commit adds two new functions to
Compositor; aboutToSwapBuffers() and bufferSwapComplete(). The
backends call these functions to set and reset the buffer-swap-pending
state.
This commit also renames a number of functions and variables to make
their meaning clear.
The act of promoting the contents of the back buffer to become the
contents of the front buffer is referred to as posting the buffer,
presenting the buffer, or swapping the buffers; rendering the buffer
is what paintScreen() does.
Moved from wayland_backend.[h|cpp] to buffer.[h|cpp] and
shm_pool.[h|cpp]. Buffer is slightly adjusted to have the ShmPool
passed in as a ctor argument and the ctor is private and friended with
ShmPool, so that it can only be constructed from ShmPool.
A Surface class is split out which holds a wl_surface and supports
attaching a buffer, setting the damage and emitting a signal when the
frame callback got called.
It doesn't come with a unit test yet as it first needs the ShmPool
and Buffer properly split out to easily set it up.
Surprisingly the DecorationShadow is modelled after the Shadow in KWin.
It provides the same offsets and a QImage exactly like the OpenGL
implementation needs it. This makes it easy to hook it into our existing
Shadow implementation with only a few changes.
Shadow now first tries to create a Shadow from the Decoration and only
if that fails it tries the X11 property. The pixmaps are not initialized
for the DecorationShadow and because of that currently only the OpenGL
backend gets initialized for DecorationShadows. The other backends might
need adjustments and also a transition to just using one image.
The Renderer gets reparented to the Deleted. While passing it to
the Deleted the Scene's implementation can ensure that the buffers
are up to date. After passing to Deleted it's no longer allowed to
call the render method.
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
If the deco part doesn't exist or the target rect is empty, KWin should
not try to composite the deco part on the screen. It can be an empty
rect for maximized windows. If the render composite is tried it results
in an error (note - man page says "This request does never generate any
errors.").
To simplify the macro is turned into a lambda.
The root cause for this problem is that PaintRedirector creates an
XRenderPicture for those invalid geometries and this requests arleady
fails. Thus RasterXRenderPaintRedirector is adjusted to not create the
XRenderPicture in that case and set it to nullptr. For a null
XRenderPicture XCB_RENDER_PICTURE_NONE is returned.
BUG: 332247
REVIEW: 117373
Returns true if the OperationMode requires KWin to composite to a
Wayland surface. This replaces the checks for the WaylandBackend or env
variable used so far in the construction of the Scene.
This backend uses an XShm pixmap for the rendering back buffer. In
present() the content of this shm pixmap is copied into a Wayland shm
buffer freeing the pixmap to be used for the next frame again and by that
we have a double buffered rendering.
In opposite to the X11 XRender backend this backend doesn't use the
overlay window.
Only the X based Scenes need an overlay window, so the Compositor doesn't
need to check for it in the Wayland case.
OverlayWindow is moved from OpenGLBackend to the sub classes which need
to provide it.
The egl wayland backend registers for the callback for a rendered frame.
This allows to throttle KWin's compositor so that we don't render frames
which wouldn't end up on the screen.
For this the Scene provides a method to query whether the last frame got
rendered. By default this returns true in all backends. The Egl Wayland
backend returns true or false depending on whether the callback for the
last frame was recieved.
In case the last frame has not been renderd when performCompositing is
tried to be called, the method returns just like in the case when the
overlay window is not visible. Once the frame callback has been recieved
performCompositing is invoked again.
An abstract backend is split out of SceneXRender which takes care of
managing the render pictures and swapping them after a frame is rendered.
Having this abstract allows to implement further backends for XRender
which do not use the Overlay Window for compositing.
To have it consistant the SceneXRender is now also created by a factory
method.
The pure virtual methods windowAdded, windowClosed, windowDeleted and
windowGeometryShapeChanged had identical implementations in both XRender
and OpenGL scene. They were accessing the hash with Scene::Windows which
is nowhere else used except for creating the stacking order in ::paint.
The implementations are moved to the base class, the only Scene specific
code is a pure virtual factory method to create the Scene window. This
already existed in SceneOpenGL to create either a SceneOpenGL1 or 2
window.
Also the hash of windows is a Scene private member now and the creation
of the stacking order is provided by a method, so that the Scene sub
classes do no longer need to access the stacking order at all.
REVIEW: 111207
Instead of having the Shadow factory method check the compositor type and
do the decision which Shadow sub class to create, a pure virtual method in
Scene is called which returns the specific Shadow sub class instance.
Instead of having the EffectFrameImpl check the compositor type and do
the decision which Scene::EffectFrame to create, a pure virtual method
in Scene is called which returns the specific Scene::EffectFrame.
Client used to have dedicated methods for different icon sizes instead
of combining all pixmaps into one QIcon. This resulted in various parts
of KWin having different access to the icons:
* effects only got one pixmap of size 32x32
* decorations only got the 16x16 and 32x32 pixmaps combined into a QIcon
* tabbox could request all icon sizes, but only as pixmap
Now all sizes are available in one QIcon allowing to easily access the
best fitting icon in a given UI.
