Windows have two kinds of repaints - window repaints and layer repaints.
The main difference between the two is that the former is specified in
the window-local coordinates while the latter is specified in the global
screen coordinates.
Window repaints are useful in case the position of the window doesn't
matter, for example for repainting damaged regions, etc.
But its biggest issue is that with per screen rendering, it's not
possible to determine what screens exactly have to be repainted. The
final area affected by the window repaint will be known only at
compositing time. If a window gets damaged, we have to schedule a
repaint on ALL outputs. Understandably, this costs a little bit in terms
of performance.
This change replaces the window repaints with the layer repaints. By
doing so, we can avoid scheduling repaints on outputs that don't
intersect with the dirty region and improve performance.
In rare cases, the Compositor has to perform a compositing if there is
nothing to repaint. For example, if a client has committed a frame
callback to get notified about the next vblank event without damaging
the surface.
Currently, if an X11 or Wayland window is damaged, we will schedule a
repaint. This results in some code duplication that this change intends
to get rid of.
A window id generated by WaylandServer may reference an X11 window
with the same id, which can result in undefined behavior.
The main reason why we needed windowId() was because of the task
switcher. However, since tabbox uses internal ids now, the window id
property can be dropped.
AnimationEffect schedules repaints in postPaintWindow() and performs
cleanup in preScreenPaint(). With the X11-style rendering, this doesn't
have any issues, scheduled repaints will be reset during the next
compositing cycle.
But with per screen rendering, we might hit the following case
- Paint screen 0
- Reset scheduled repaints
- AnimationEffect::prePaintScreen(): update the timeline
- AnimationEffect::postPaintScreen(): schedule a repaint
- Paint screen 1
- Reset scheduled repaints
- AnimationEffect::prePaintScreen(): destroy the animation
- AnimationEffect::postPaintScreen(): no repaint is scheduled
- Return to the event loop
In this scenario, the repaint region scheduled by AnimationEffect will
be lost when compositing is performed on screen 1.
There is no any other way to fix this issue but maintain repaint regions
per each individual screen if per screen rendering is enabled.
BUG: 428439
The sliding popups effect schedules a repaint and then unreferences the
deleted window. The problem with doing so is that the scheduled repaint
will be effectively discarded because the Deleted will be destroyed once
we are back in the event loop.
This issue is most noticeable on Wayland. Not sure why. If you close
Kickoff, you may see its flickering ghost in background.
If it happens that a Deleted has a pending repaint, transform it into a
workspace repaint to avoid discarding any scheduled repaints.
SurfaceInterface::inputIsInfinite() has been dropped. If the surface has
no any input region specified, SurfaceInterface::input() will return a
region that corresponds to the rect of the surface (0, 0, width, height).
While the new design is more robust, for example it's no longer possible
to forget to check SurfaceInterface::inputIsInfinite(), it has shown some
issues in the input stack of kwin.
Currently, acceptsInput() will return false if you attempt to click the
server-side decoration for a surface whose input region is not empty.
Therefore, it's possible for an application to set an input region with
a width and a height of 1. If user doesn't know about KSysGuard or the
possibility of closing apps via the task manager, they won't be able to
close such an application.
Another issue is that if an application has specified an empty input
region on purpose, user will be still able click it. With the new
behavior of SurfaceInterface::input(), this is no longer an issue and it
is handled properly by kwin.
If the shadow is destroyed immediately before the window is destroyed,
we need to schedule a workspace repaint in order to prevent showing a
"ghost" shadow.
BUG: 425294
This change replaces the remaining usages of the old connect syntax with
the new connect syntax.
Unfortunately, there are still places where we have to use SIGNAL() and
SLOT() macros, for example the stuff that deals with d-bus business.
Clazy was used to create this change. There were a few cases that needed
manual intervention, the majority of those cases were about resolving
ambiguity caused by overloaded signals.
Instead of looping through the rects in the region, emit the region at
bulk. It reduces the amount of emissions we do and allows us to pack the
response accordingly.
Toplevel::debug() is one of annoyances that you need to deal with when
implementing a new client type. It can be tempting to just write "this"
to the stream, but it will result in a crash.
In order to make implementing new client types easier, this change
introduces a debug stream insertion operator overload that works for all
kinds of the Toplevel class.
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.
Currently, we update the input transformation matrix for the focused
pointer surface only when the frameGeometryChanged() signal is emitted.
However, since the input transformation matrix is computed based on the
current position of the upper left corner of the main surface, it is
wrong to do so because the frame geometry is a logical geometry that
doesn't have any direct relationship with the buffer geometry, i.e. the
rect on the screen occupied by the main surface.
If the input transformation matrix gets out of sync, user may notice
that pointer events are "shifted."
This change introduces a new signal that's emitted when the input
transformation matrix has been changed. Input related components in kwin
can connect to it to keep a copy of the input transformation matrix in
SeatInterface in sync. Under the hood, the new signal is just an alias
for the bufferGeometryChanged() signal.
In most cases, we don't need to react to client geometry changes, but in
code that deals with server-side window decorations, we need to react to
client geometry changes. The problem is that frame and client geometry
updates are not correlated even though there is a connection between the
frame geometry and the client geometry.
This change introduces the client geometry in the Toplevel class in order
to allow monitoring client geometry updates from DecoratedClientImpl.
There's some X11-reliance in Toplevel which is ideally split out but for now let's check for info being null.
For instance, accessing pid() on a deleted Wayland client can crash when it's no longer a XdgShellClient.
Differential Revision: https://phabricator.kde.org/D28101
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:
When a window is being interactively resized, its contents may jump. The
reason why that happens is because KWin renders partially resized client
window. Composite extension spec says that a window will get a new pixmap
each time it is resized or mapped. This applies to the frame window, but
not to the client window itself. If the client window is resized,
off-screen storage for the frame window won't be reallocated. Therefore,
KWin may render partially resized client window if the client doesn't
attempt to be in sync with our rendering loop. Currently, the only way
to do that is to use extended frame counters, which are not supported by
KWin.
So, in order to fix visual artifacts during interactive resize, we need
somehow forcefully re-allocate off-screen storage for the frame window.
Unfortunately, Composite extension doesn't provide any request to do
that, so the only option we have is to resize the frame window.
BUG: 415839
FIXED-IN: 5.18.0
Reviewers: #kwin
Subscribers: davidedmundson, ngraham, alexde, fredrik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26914
Summary: The new name better reflects what Toplevel::geom is.
Test Plan: Compiles, tests still pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25738
This reverts commit 9151bb7b9e.
This reverts commit ac4dce1c20.
This reverts commit 754b72d155.
In order to make the fix work, we need to redirect the client window
instead of the frame window. However, we cannot to do that because
Xwayland expects the toplevel window(in our case, the frame window)
to be redirected.
Another solution to the texture bleeding issue must be found.
CCBUG: 257566
CCBUG: 360549
Summary:
Since KDE 4.2 - 4.3 times, KWin doesn't paint window decorations on real
X11 windows, except when compositing is turned off. This leaves us with
a problem. The actual client contents is inside a larger texture with no
useful pixel data around it. This and decoration texture bleeding are
the main factors that contribute to 1px gap between the server-side
decoration and client contents with effects such as wobbly windows, and
zoom.
Another problem with naming frame pixmap instead of client pixmap is
that it doesn't quite go along with wayland. It only makes more difficult
to abstract window quad generation in the scene.
Since we don't actually need the frame window when compositing is on,
there is nothing that holds us from redirecting client windows instead
of frame windows. This will help us to fix the texture bleeding issue
and also help us with the ongoing redesign of the scene.
Test Plan: X11 clients are still composited.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25610
Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
Summary:
KDE is known for having a strong view on the client-side decorations vs
server-side decorations issue. The main argument raised against CSD is
that desktop will look less consistent when clients start drawing window
decorations by themselves, which is somewhat true. It all ties to how
well each toolkit is integrated with the desktop environment.
KDE doesn't control the desktop market on Linux. Another big "player"
is GNOME. Both KDE and GNOME have very polarized views on in which
direction desktop should move forward. The KDE community is pushing more
toward server-side decorations while the GNOME community is pushing
more toward client-side decorations. Both communities have developed
great applications and it's not rare to see a GNOME application being
used in KDE Plasma. The only problem is that these different views are
not left behind the curtain and our users pay the price. Resizing GTK
clients in Plasma became practically impossible due to resize borders
having small hit area.
When a client draws its window decoration, it's more likely that it also
draws the drop-shadow around the decoration. The compositor must know
the extents of the shadow so things like snapping and so on work as
expected. And here lies the problem... While the xdg-shell protocol has
a way to specify such things, the NetWM spec doesn't have anything like
that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with
it is that it's a proprietary atom, which is specific only to GTK apps.
Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing
anything like that would require major changes in how we think about
geometry.
Recent xdg-shell window geometry patches adjusted geometry abstractions
in kwin to such a degree that it's very easy to add support for client
side decorated clients on X11. We just have to make sure that the
X11Client class provides correct buffer geometry and frame geometry when
the gtk frame extents are set.
Even though the X11 code is feature frozen, I still think it's worth
to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize
issues. Also, because KWin/Wayland is unfortunately far from becoming
default, it will help us with testing some implementation bits of the
window geometry from xdg-shell.
BUG: 390550
FIXED-IN: 5.18.0
Test Plan:
Things like quick tiling, maximizing, tiling scripts and so on work as
expected with GTK clients.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: cblack, trmdi, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24660
Summary:
Currently our Scene is quite naive about geometry. It assumes that the
window frame wraps the attached buffer/client. While this is true for X11
clients, such geometry model is not suitable for client-side decorated
clients, in our case for xdg-shell clients that set window geometry
other than the bounding rectangle of the main surface.
In general, the proposed solution doesn't make any concrete assumptions
about the order between frame and buffer geometry, however we may still
need to reconsider the design of Scene once it starts to generate quads
for sub-surfaces.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24462
Summary:
The damage region is in surface-local coordinates, while the repaints
region is in frame-local coordinates, i.e. relative to the top-left
corner of the frame geometry.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24460
Summary:
Frame and buffer geometry don't have strict order. Either one of them can
be inside the other one, so we must take that into account when computing
visible bounds of the client including drop-shadows. We also have to take
sub-surfaces into account when determining the visible rect, however it's
out of scope for this patch.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24458
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:
Currently each managed X11 client is represented with an instance of
Client class, however the name of that class is very generic and the
only reason why it's called that way is because historically kwin
was created as an x11 window manager, so "Client" was a sensible choice.
With introduction of wayland support, things had changed and therefore
Client needs to be renamed to X11Client in order to better reflect what
that class stands for.
Renaming of Client to X11Client was agreed upon during the last KWin
sprint.
Test Plan: Compiles, the test suite is still green.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24184
Summary:
So far wayland was used by internal clients to submit raster buffers
and position themselves on the screen. While we didn't have issues with
submitting raster buffers, there were some problems with positioning
task switchers. Mostly, because we had effectively two paths that may
alter geometry.
A better approach to deal with internal clients is to let our QPA use
kwin core api directly. This way we can eliminate unnecessary roundtrips
as well make geometry handling much easier and comprehensible.
The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
style use platform-specific APIs to set and unset shadows. We need to
add shadows API to KWindowSystem. Even though some internal clients lack
drop-shadows at the moment, I don't consider it to be a blocker. We can
add shadows back later on.
CCBUG: 386304
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T9600
Differential Revision: https://phabricator.kde.org/D22810
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:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
QRegion::rects was deprecated in Qt 5.11. It is advised to use begin()
and end() methods instead.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22353
Summary:
Compositing today is ubiquitous. There is no reason to keep compositing
specific functions of Toplevel, Client and Workspace classes in the
composite.cpp source file. Instead let these definitions be separated.
Test Plan: Compiles
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D21654
