GitLab

Currently, the shape region is not copied to the Deleted. If either
SurfaceItemX11 or SurfaceItemXwayland needs to build quads for a shaped
window, it won't be able to do so properly because the corresponding
x11 window is long time gone.

If the shape region changes before the window is unmapped, you may still
see visual artifacts. Unfortunately, the only way to fix that bug is to
switch to wayland.

BUG: 440001
BUG: 438458
BUG: 435378

Originally, only x, y, width, and height property setters were used. A
bit later "position" and "size" helper setters were added to simplify
code in SurfaceItem sub-classes. It seems like setX(), setY(), setWidth(),
and setHeight() are unused now, so remove them.

The XDamageDestroy has a weird requirement saying that it can be called
as long as the X11 window is still valid. On the other hand, one could
argue that it is more intuitive if the damage handle becomes inert if the
associated window is destroyed. Unfortunately, that's not the case and
as git history shows, it's an easy way to shoot yourself in the foot, we
had the exact warning many years ago.

The problem with the XDamageDestroy API is that it is simply unreliable
given the asynchronous nature of communication between kwin and xorg.

Anyway, with X11 sunsetting, let's destroy the damage handle only when
the X11 window is unmapped and not bother too much about it.

It is error-prone to have multiple sources for the same data. If the
base implementation (Compositor::compositing()) changes, other helpers
can get out of sync.

When finishing compositing, Workspace::compositing() will return true,
but it will be preferred if it returns false instead so kwin can properly
update x11 window visibility status, etc.

Instead of checking whether the compositor has a scene, check the status
of the compositor. It will not be "On" during teardown.

In C++20, there will be emit() class member, which can conflict with the
emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by
default in the future.

See also
https://lists.qt-project.org/pipermail/development/2020-February/038812.html

They are used only by X11Client, so make X11Client call relevants
methods on the surface item directly instead. In hindsight, it will be a
really good idea to make SurfaceItemX11 and SurfaceItemXwayland(?)
automatically manage the window pixmap. However, it can be done once
an item freezing api is added and we fix the cross-fade animation.

Currently, items depend on scene windows for creating pixmaps, repaint
scheduling, and caching quads.

This change moves repaint scheduling from scene windows to items to
make the scene items depend less on scene windows.

In hindsight, we may clean up the repaint scheduling machinery further
by introducing view objects.

The Toplevel::clientContentPos() function is needed to map the surface
local coordinates to the global coordinates. But its name is highly
confusing as there's already a function with a similar name. This change
introduces a helper with a better name to fix the readability issue.

This makes the implementation of the buffer geometry consistent with the
frame geometry and the client geometry and removes a virtual method call
from a few hot paths.

It makes no sense on Wayland.

Currently, dealing with sub-surfaces is very difficult due to the scene
design being heavily influenced by X11 requirements.

The goal of this change is to re-work scene abstractions to make improving
the wayland support easier.

The Item class is based on the QQuickItem class. My hope is that one day
we will be able to transition to QtQuick for painting scene, but in
meanwhile it makes more sense to have a minimalistic internal item class.

The WindowItem class represents a window. The SurfaceItem class represents
the contents of either an X11, or a Wayland, or an internal surface. The
DecorationItem and the ShadowItem class represent the server-side deco and
drop-shadow, respectively.

At the moment, the SurfaceItem is bound to the scene window, but the long
term plan is to break that connection so we could re-use the SurfaceItem
for things such as software cursors and drag-and-drop additional icons.

One of the responsibilities of the Item is to schedule repaints as needed.
Ideally, there shouldn't be any addRepaint() calls in the core code. The
Item class schedules repaints on geometry updates. In the future, it also
has to request an update if its opacity or visibility changes.

This signal can be useful if you want to know when the visible geometry
has changed to update cached repaint region during an animation.

It can be expressed via other means.

"rect"s have their origin at the top-left corner of the frame. However,
visibleRect() returns a QRect that's in the global coordinates.

Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.

This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.

We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.

The major difference between this version and the previous is that kwin
no longer forwards the opacity to the app window if it runs as a
window window manager and a compositing manager. As Keith Packard said [1]

> The window manager support is only needed to forward the property from the
> application window to the frame; with the Composite extension, a
> compositing manager can then take that value into account when
> constructing the desktop image.  Any X server can implement the Composite
> extension; the one in the X server project at freedesktop.org is just one
> such.  It would be trivial to implement this extension in a direct FB
> based X server, or any other X server which places windows in off-screen
> images.

There are a couple of reasons to do so: (a) simplifies code, (b) we don't
temper with opacities on override-redirect windows.

[1] https://listman.redhat.com/archives/xdg-list/2003-December/msg00153.html

The rest of code assumes that it's qreal.

We cannot use addDamage() in getDamageReply() because the former sets
back the m_isDamaged flag.

If only frame callbacks have been committed, the compositor must still
schedule compositing.

BUG: 428499

This avoids mapping the visible rect between the window local
coordinates and the global coordinates back and forth.

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.

The new helpers are designed for the purpose of mapping points from the
global screen coordinates to the frame-local and the surface-local coords

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.

Vlad Zahorodnii authored Jul 14, 2020 and Vlad Zahorodnii committed Jul 17, 2020

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.

Vlad Zahorodnii authored Jun 19, 2020 and Vlad Zahorodnii committed Jun 24, 2020

SurfaceInterface::scale() has been renamed to SurfaceInterface::bufferScale().