The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
Summary:
Currently we have two signals that are emitted when the Toplevel's geometry
changes - geometryShapeChanged() and geometryChanged(). The former signal
is used primarily to invalidate cached window quads and the latter is
sort of emitted when the frame geometry changes. But it's not that easy. We
have a bunch of connects that link those signals together...
The worst part about all of this is that the window quads cache gets
invalidated every time a geometry update occurs, for example when user
moves a window around on the screen.
This change introduces a new signal and deprecates the existing geometryChanged
signal. frameGeometryChanged is similar to geometryChanged except that it is
emitted when an _actual_ geometry change has occurred.
We do still emit geometryShapeChanged signal. However, in long term, we
need to get rid of this signal or come up with something that makes sense
and doesn't require us to waste computational resources.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26863
Summary:
In order to properly implement xdg_surface.set_window_geometry we need
two kinds of geometry - frame and buffer. The frame geometry specifies
visible bounds of the client on the screen, excluding client-side drop
shadows. The buffer geometry specifies rectangle on the screen that the
attached buffer or x11 pixmap occupies on the screen.
This change renames the geometry property to frameGeometry in order to
reflect the new meaning assigned to it as well to make it easier to
differentiate between frame geometry and buffer geometry in the future.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24334
Summary: getShadow is not a getter method as it doesn't return a shadow.
Test Plan: Compiles.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24298
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: readX11ShadowProperty fails without an X connection
Test Plan: Tested by Kai who didn't have xwayland
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21965
Summary:
If updating a shadow means that there should be no shadow, shadow ends
up deleting itself midway through the method.
It's cleaner and safer to leave that to the caller.
This new change matches the existing documentation for
Shadow::updateShadow which states
> In case the Property has been withdrawn the method returns @c false.
> In that case the owner should delete the Shadow.
Test Plan:
Created an ASAN of kwin
Relevant testMaximised no longer fails
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17380
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:
Otherwise it crashes for the first window being created in a
KWin/Wayland without XWayland support.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7894
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:
Toplevel::window() is the actual X11 window. This makes it difficult
to use as the generic identifier for both X11 and Wayland. The Wayland
ShellClient already had a windowId() which is now added to Toplevel as
a virtual method. On X11 (Toplevel default) it returns the window().
The method window() now returns XCB_WINDOW_NONE for classes without
the Toplevel::m_client, such as ShellClient. Thus it allows to properly
check whether we are on Wayland or X11.
The code is adjusted to use windowId where a generic id is needed and
to properly check whether the window is valid before using it where
a window() is used.
This also fixes at least one additional unknown issue in
Workspace::setActiveClient
where the windowId of a Wayland client was passed to X11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1527
Summary:
From the rest of this method, it is obvious that m_topLevel can
be null in any part of the method - we are checking against it
being null in a few places in the method - both before and after
the affending lines.
Now, there is one place where the check is not applied, and
potentially calls ->window() on the null pointer.
p.s. If there are more places where kwin does clear_or_something(); return;
it could benefit from introducing on_scope_exit and similar tricks - see
Alexandrescu's 'Declarative control flow' presentation.
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1346
For Wayland clients we now are able to get shadows.
Internally this reuses large parts of the X11 implementation. This
could be improved to make the Scene's better aware of the Wayland
shadow, so that less memory is needed.
If there were already a shadow, the quads are rebuild, but not if
we created a new shadow. This is not a problem if the shadow exists
before the quads are built for the first time (e.g. when managing
the window), but if the shadow is created later on the quads are
incorrect and the shadow doesn't get rendered at all. This happens
for example with Aurorae based decoration themes, where the creation
of the first shadow is delayed into the next event cycle.
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
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 Xcb::Property can wrap the xcb_get_property call and provides
convenient access methods to read the value of the reply with checks
applied. For this it provides a templated ::value method for reading a
single value or reading an array. There's also a ::toBool and
::toByteArray which performs the conversion directly with default values
for the type and format checks.
Xcb::TransientFor is changed to be derived from Property instead of
Wrapper directly, so that the reading of the property value can be
shared.
Xcb::StringProperty is a convenient wrapper derived from Property to
handle the reading of a string property providing a cast to QByteArray
operator. This replaces the ::getStringProperty from utils. Though the
separator functionality from ::getStringProperty is not provided as that
is only used in one function and handled there.
All the custom usages of xcb_get_property or getStringProperty are
replaced to use this new wrapper. That simplifies the code and ensures
that all properties are read in the same way.
REVIEW: 117574
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.
Main problem here was that it still used fromX11Pixmap. It's changed to
XCB and gets the image data with xcb_get_image, constructs a QImage from
retrieved data and copies it to QPixmap. That's performing a deep copy
which we want (and also had in the old code).
The CompositingType enum turns into flags and two new values are
introduced: OpenGL1Compositing and OpenGL2Compositing.
Those new values are or-ed to OpenGLCompositing so that a simple check
for the flag OpenGLCompositing works in case of one of those two new
values. To make the generic check for OpenGL compositing easier a method
in EffectsHandler is introduced to just check for this.
The scenes now return either OpenGL1Compositing or OpenGL2Compositing
depending on which Scene implementation. None returns OpenGLCompositing.
The Oxygen deco uses this to remove built-in shadows from decorated windows when adding (legacy...) decoration shadows
CCBUG: 291774
REVIEW: 103751
(cherry picked from commit a97bdc64fa2a676f99738abd371a99126fb8e93d)
Due to changes in build system we have always either OpenGL or OpenGL ES.
This allows to remove the KWIN_HAVE_OPENGL_COMPOSITING define. In the
effects the define is kept as KWIN_HAVE_OPENGL which can be used in
future to build also an XRender only effect system.
Copies the shadow parts into one image and creates a GLTexture
from the image, so that we can render the complete shadow with
just one texture and one painting pass.
Should remove most of the overhead involved when rendering the new Shadows.
As a side effect this should fix missing shadows with non-NPOT GPUs and
a rendering glitch reported with NVIDIA.
REVIEW: 101742
The deep copy does not work with raster as it creates a non-native
pixmap. In fact the deep copy is not needed any more as it was a
safety check during development when apps using raster could crash
kwin.
In order to notice when the geometry changes a new signal is
added to toplevel and both Unmanaged and Client connect all their
signals which are emitted whenever the geometry changes in some way
to this new signal.
Shadow connects to the signal and updates the quads and region
whenever the size changes.
The Shadow is clearly an aspect of the compositor. Therefore the
Shadow has to be owned and controlled by the Scene::Window.
Nevertheless Toplevel needs to know about the Shadow cause of reading
the property.
Unmanaged needs to repaint the complete geometry including shadow
when it ends compositing. Therefore we need to track the shadow
passing to deleted correctly. Disadvantage: when turning off
compositing the shadow is kept. Need to solve in a better way!
Vlad Zahorodnii