Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
Switch to Q_ASSERT in order to make code a bit more consistent. We have
places where both assert and Q_ASSERT are used next to each other. Also,
distributions like Ubuntu don't strip away assert(), let's hope that
things are a bit different with Q_ASSERT.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23605
Summary:
This usage of QWeakPointer has been deprecated since Qt 5.0, since it
leads to really confusing API - usually you must never dereference a
QWeakPointer directly, but always go through QSharedPointer, except in
this one case, where it's permissible.
The thumbnails are only referenced in one place, this change is straight-forward.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23070
Summary:
When ~Scene is called, it's not guaranteed that backend is still valid
or that there is current opengl context. So, generally speaking,
deleting scene windows in ~Scene is a bad idea.
It's okay not to delete scene windows in ~Scene because current
implementation of Compositor::finish ensures that they don't last longer
than the scene.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19540
Summary:
Code that destroys all scene windows when finishing compositing is not
readable. E.g. can you tell what this piece of code is doing without
looking into the source code of Scene::windowClosed?
foreach (Client * c, Workspace::self()->clientList())
m_scene->windowClosed(c, NULL);
This change intoduces removeToplevel(as well its counterpart) method to
the Scene class. The name of the new method much better describes what
we're doing.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18210
Summary:
Given that allclips contains opaque regions of higher windows, we should
check PAINT_WINDOW_TRANSLUCENT flag instead of PAINT_WINDOW_TRANSFORMED.
ba39d1f917 introduced that check. Neither
the commit message nor the associated review have any comments regarding
checking PAINT_WINDOW_TRANSFORMED, so given the following comment
// Here we rely on WindowPrePaintData::setTranslucent() to remove
// the clip if needed.
PAINT_WINDOW_TRANSFORMED is most likely a typo.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18236
Summary:
We initialize all fields of Phase2Data at once, so the constructors seem
to be redundant.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18207
Summary:
We know that the maximum size is the number of windows in stacking
order. It might be that some are skipped as they are not ready for
painting, but overall it's better to reserve a little bit too much
memory than to have a growing QVector.
Test Plan: Compiles
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18208
Summary:
Given that QList<T> will allocate items on the heap when sizeof(T) is
bigger than sizeof(void *), which is the case for Phase2Data, use
QVector instead.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18198
Summary:
Phase2Data already includes the scene window, so we don't have to store
it again in QPair.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18188
Summary:
213239a0ea tried to address the case when
a wayland client gets shadow after it was mapped, but because of poor
testing from my side, another bug was introduced. If a decoration tooltip
or the user actions popup is shown, then in some cases it can be blank.
Usually, SurfaceInterface::shadowChanged proceeds SurfaceInterface::sizeChanged,
so when the shadow is installed, window quads cache is rebuilt. But
because shell client already knows the geometry of the internal client,
goemetryShapeChanged is not emitted, thus the cache is not updated.
It would be better just to invalidate the cache when the shadow is
installed, uninstalled, or updated. This reduces the number of
unnecessary invocations of Scene::Window::buildQuads and also moves
handling of the window quads cache away from the Shadow class.
BUG: 399490
FIXED-IN: 5.15.0
Test Plan: Decoration tooltips are no longer blank.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17215
Summary:
qDeleteAll can be used to delete values in QMap or QHash. Please notice
that qDeleteAll calls `delete` only for values, not keys.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13822
Summary:
Under wayland we support high DPI putting by putting a separation
between the logical co-ordinate system and the resolution of rendered
assets.
When a window is on a high DPI screen, we should render at the higher
resolution.
Like the window scaling this handles any combination of a 2x scaled
decoration being rendered on a 1x screen or vice versa.
---
This patch is a bit different from the other scaling stuff. We have to
generate the quads *before* we have an updated texture with the new
scale. This means the scale isn't attached to the buffer like elsewhere.
That's why I added a property in TopLevel so there's still one canonical
source and things can't get out of sync.
BUG: 384765
Test Plan:
Crystal clear breeze and oxygen decos on my @2x display
Drag windows to attached @1x display, things still look OK when across 2
screens
Changing the scale of a screen updated the decos instantly
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8600
Summary:
We had a few places (e.g. DebugConsole, Platform) where the Scene was
cased into a SceneOpenGL to access the backend and get the extensions.
This change simplifies that by adding a virtual method to Scene directly
which is implemented in SceneOpenGL and returns the backend's
extensions.
Thus the casts to SceneOpenGL are no longer required.
Test Plan:
Opened debug console to verify extensions are listed,
triggered Outline to verify the sharing QPA context gets created.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7734
Needed by testing of QPainter scene to access the back buffer. Exposed
as a virtual method in Scene, so that the test does not have to cast to
SceneQPainter.
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:
Currently when a client changes it's buffer size the result is corrupt
until we move the window.
When a client buffer scale changes we need to redraw the whole window,
and most importantly flush the cached window quads, which reference the
scale.
This is not handled by the doSetGeometry() from the size changing as the
normalised size of the client remains the same so it no-ops.
Test Plan:
Opened gtk3-demo and changed screen scale. It's now perfect.
Patch for Qt to work correctly incoming.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7486
Summary:
So far EffectsHandlerImpl directly accessed SceneQPainter::painter
through a dynamic cast. If in future the QPainter based compositor should
be moved into a plugin we cannot access it through a dynamic cast.
To solve this problem the painter method is moved into Scene as
a virtual method returning a sane default value.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7214
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
Summary:
WindowVertex contains the x position and also the relative texture x position
Our textures are scaled bigger than kwin's resolution, so this makes sure we set the right
texture position.
Otherwise our final array ends up using 0 to 0.5 of the texture, not 0 to 1.
Test Plan:
Opened some 2x windows, on a 1x output.
It looked how it should do, instead of it being double the size and cropped
Tested some things that use quads, like wobbly windows
Reviewers: #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3502
Summary:
On Wayland per output rendering is performed and paintScreen is invoked
for every output. Some effects need the information which output is
currently being rendered as otherwise e.g. FBO access could fail.
This change adds the current output geometry to ScreenPaintData. On X11
(all outputs one geometry) this information is not set and a null rect
is returned. That way the effects can also easily check which rendering
mode is used.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3058
Summary:
So far when deleting a Shadow we used deleteLater which caused it
to be deleted in the next event cycle. This could in worst case result
in the Shadow being deleted after compositing got suspended. Thus the
Shadow not getting removed from the DecorationShadowCache which in
turn would mess up rendering on resume of compositing as the cache
returns a texture created for a different context.
BUG: 361154
FIXED-IN: 5.7.4
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2483
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.
Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.
By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.
It's clearly something we tried to hide from the user that it exists.
For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.
Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.
Reviewers: #kwin, #plasma, #vdg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2180
Summary:
So far when a ShellClient got unmapped ready_for_painting was set to
false. That is the ShellClient was treated in the same way as a not
yet shown window. It was completely excluded from painting, a close
animation impossible.
This change makes use of the functionality available in
Client::hiddenInternal(). The window is considered as hidden, thus
still excluded from e.g. getting input events, but could be rendered
any time as we still have a previous window pixmap (if referenced).
This allows to have it considered in the rendering pass, but effects
still cannot make use of it as that state is not yet exposed to the
effects.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2083
Summary:
Our Wayland compositors cannot composite an X11 pixmap. Thus even
if we succeed in creating the pixmap, the changes would not get to
the scene. The code allowed for situation where a surface is not yet
set to fall back to the X11 code path. This can happen for XWayland
windows.
Test Plan: Crash in xclipboardsynctest without the change
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2010
Summary:
To check which code path we should take just check whether
* we have a surface -> Wayland
* we have a pixmap -> X11
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1487
This change introduces a tree for WindowPixmap. A WindowPixmap can
have a parent WindowPixmap and children. Each child represents a
SubSurface and references the buffer of that SubSurface.
The tree of WindowPixmaps is updated each time updateBuffer is called.
If there are new SubSurfaces new WindowPixmaps are created, for removed
SubSurfaces the old WindowPixmap gets removed. Also the ordering is
updated to reflect the current state.
This is currently rather expensive and should be changed to only rebuild
the tree if it actually changed.
The screen projection matrix is needed if an effect wants to customize
the modelview projection matrix while rendering a window and keeping
the currently applied screen projection and transformation.
With this change a new ctor overload is added to ScreenPaintData
which allows passing a projection matrix through the effects. This
allows effects to put up custom shaders with a shared projection matrix
and without having to calculate it themselves.
The projection matrix is a read-only information for the effects. There
is no way to change or overwrite it.
This describes an additional offset for the client content. On X11
our client content position matches with the window - the window
decoration is part of the overall content coordinate system.
On Wayland the content is an own texture starting at 0/0. Thus a
mapping to texture coordinates will be required when server side
decorations are provided. The new information is used in the scene's
to adjust the rendering and generating of quads.
The last stage for window rendering is triggered by
Scene::finalDrawWindow. Adding a security check there if screen is locked
no non-lock screen window should be rendered.
Unfortunately this method is virtual so the check needs to be done in the
base and all implementing child methods (currently only OpenGL).
REVIEW: 126144
This change introduces a mechanism for internal windows to be rendered
to a QOpenGLFramebufferObject to be composited using the texture bound
to the FBO. This is useful for in-process rendering (e.g. QtQuick) and
at the same time bypassing the windowing system.
The OpenGL context of the QOpenGLFramebufferObject needs to be sharing
with the compositing OpenGL context.
When we don't use the buffer anymore, we should discard it. Otherwise
we start to leak buffers and that can result in clients dead locking
while waiting for more free buffers.
The concept of Buffers do not match WindowPixmap perfectly. With X11
we had a pixmap as long as the size was the sime, then it got discarded.
With Wayland we get a new Buffer whenever the window gets damaged.
Furthermore the Buffer might get destroyed any time (especially if the
client disconnects) or the data becomes invalid (it's a shm section after
all).
This adds some constraints on how the Buffer can be used. It's suggested
that the implementing sub-classes do a deep copy of the Buffer's data
when accessing it. For OpenGL that's rather obvious, for QPainter it
needs a dedicated QImage::copy.
WindowPixmap holds a pointer to the currently used Buffer, but doesn't
guarantee that it stays valid. Every time the window gets damaged, the
pointer needs to be updated.
The QPainter based scene is the first to implement support for Buffers:
on creation a deep copy is performed, on damage the changed parts are
painted into the deep copy.
