There are a couple of reasons why it's worthwhile doing:
The first is that it makes the logic in the updateServerGeometry()
function reusable for the interactive code path. As of now, when the
window is being interactively resized, doInteractiveResizeSync() will
issue some xcb_configure_window() calls but then it also implicitly
assumes that updateServerGeometry() will call updateShape() and
updateInputWindow() but skip m_frame.setGeometry() later. That is
confusing, and error prone. For example, if somebody drops
m_lastFrameGeometry in favor of m_frame.geometry() (which is an
absolutely reasonable thing to do btw!!), a regression will be
introduced: things would appear to work at first, but then eventually
bug reports about input working weirdly would start piling up.
The second is hidpi scaling of wayland clients. toXNative(a + b + c)
is not the same as toXNative(a) + toXNative(b) + toXNative(c). By
switching to the device geometry, we leave less space for making an
error.
The third is that lets us clean up some geometry manipulation code.
When dealing with window hierarchies, it's more convenient to have
m_window.position() rather than a dedicated property in the X11Window
class such as wrapperPos().
If the logical geometry changes, the X11Window still needs to verify
whether the currently applied native geometry differs from it. In order
to do that, the X11Window needs to map the logical geometry to the device
pixels. Given that X11Window already maps the logical pixels to the
device pixels, the Xcb::Window doesn't need to map the geometry again.
Also, the way different coordinate spaces are handled now is inconsistent.
Some things (Xcb::Window) work only with the logical pixels, while other
(e.g. client messages) require the user manually mapping the geometry
between the different coordinate spaces. With this change, it would be
more consistent.
Regarding the porting process, it was performed in a single step because
all the code that changes or reads Xcb::Window geometry is neatly
encapsulated in the X11Window class in a couple of functions.
The mastering display colorimetry describes what part of the colorspace
is actually used, which is important when we're sending desired metadata
about a screen using the rec.2020 container colorspace, or when the client
uses an "infinite" / extended colorspace like scRGB
This is to prevent disconnecting clients that sometimes struggle with
keeping up with the events that the compositor sends. 1 MiB was eyeballed.
Wayland's wire protocol consists of a stream of messages. Every message
consists of a header (2 words: 1 word for object id, the other word
specifies the message size + event/request opcode) and the arguments.
Considering the compositor sending motion events generated by a mouse
with 1000Hz polling rate, we have
- wl_pointer.motion event size: (4 bytes for serial + 4 bytes for x +
4 bytes for y + 8 bytes for header) = 20 bytes
- wl_pointer.frame event size: 8 bytes for header
So in total, if the client freezes for a second, the client buffer size
should be at least (20 + 8) * 1000 / 1024 = 27 KiB. 1 MiB corresponds to
the client not processing the motion events for approximately 30 seconds.
Some old hardware is very limited in the amount of instructions it can support.
In order to not have KWin fail to composite, reject using hardware acceleration
in this case and fall back to llvmpipe or QPainter
BUG: 482868
This helps avoid some frame drops after the GPU may have went into a lower power
state. While this isn't generally noticeable, avoiding this makes noticing and
debugging actually relevant frame drops easier
CCBUG: 488843
Makes it so the GlobalShortucts object gets built and its KGlobalAccelD
parts get disabled.
Addresses the TODO in GestureHandler.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
If a SwipeGesture or a PinchGesture is cancelled, the associated QAction
is going to be triggered. It is against the expectations of the gesture
handlers.
In order to address that, this ports the gesture handlers to the native
gesture apis, which expose whether the gesture has been started or cancelled
better.
After !5532 a new code path was triggered during Workspace::rearrange call.
When first Polonium window opens on any screen, there is no active tile yet.
This forces geometry calculation in Window::checkWorkspacePosition -> Window::ensureSpecialStateGeometry
To return empty QRect, which depending on the screen arrangement will move window to the other screen.
This confuses Polonium plugin, as it receives wrong outputChanged signal in scripting API.
BUG: 488898
Signed-off-by: Alik Aslanyan <inline0@pm.me>
The currently used cursor theme can be different from the configured one.
For example, if the configured theme cannot be used.
In order to ensure that that case is handled well, this change makes the
shake cursor plugin uses the same cursor theme as PointerInputRedirection.
At the moment, the shake cursor respects the current cursor shape. But
there are couple of drawbacks behind doing it: the first is that it's
very likely that the cursor pixmap has low resolution, the second is
the cursor can be hidden client-side.
This change makes the shake cursor plugin load the Xcursor theme with
a high enough size and display the default cursor shape regardless of
what the client has set in order to address the two aforementioned issues.
At the moment, the FocusChain has Q_ASSERT()s to prevent inserting closed
windows back into the focus chain. It makes sense on paper. But, there
are code paths that could still hypothetically call FocusChain::update(),
they are harmless except the logic in the FocusChain.
So instead this change makes the FocusChain ignore closed windows, i.e.
take a more defensive approach. There are a few reasons why it's
worthwhile doing: the first is that it would prevent inserting closed
windows back into the focus chain in release builds and potentially even
back into the stack, debugging such crashes is absolutely no fun; the
second is that it would be preferred to avoid sprinkling random
isDeleted() checks in the Window code here and there and thus making
the code harder to follow.
Otherwise we might miss some changes that come without a hotplug event,
like adaptive sync becoming available after the output has been initialized
BUG: 486149
It's printed whenever any opengl context is created, which can flood the
logs. On the other hand, this information is also included in the support
information, which we often ask in the bug reports.
BUG: 489000
Data like target vs. actual pageflip time, and render times is often needed for
debugging or optimizing render time predictions, so this commit makes KWin print
that information to a file in the home directory whenever KWIN_LOG_PERFORMANCE_DATA
is set.
CCBUG: 488843
Now that they will be shown and hidden in the proper state, we can set
up the input panel slide as the window gets added and ignore the
geometry changes that it will have in its lifetime.
Do not markAsMapped an unpositioned panel, it would confuse the sliding
popups effect and force it to figure out its state in creative ways.
Mark the panel window as hidden as it gets destroyed.
These flags affect kwin in general so WaylandServer is not the best place
for them to live in. For such things, we typically add properties in the
Application object, which is what this change does.
The way the glide effect works is that it takes 2D geometry and applies
the perspective projection to it on the CPU side. The reason we do it is
that the scene is 2D.
However, this leaves us with the well known problem where a texture
that's mapped to a trapezoid won't be correctly interpolated along the
diagonal.
It can addressed by performing a perspective division in the fragment
shader, but given the way the effect is structured, it's off the table. So
instead subdivide the window grid.
BUG: 488840
