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:
Under wayland we support high DPI putting by putting a separation
between the logical co-ordinate system and the resolution of rendered
assets.
I didn't include window decorations in the previous wayland scaling
patchset. They were drawn them at a standard resolution, which is
implicitly scaled up.
This uses the Qt scaling, meaning oxygen and breeze (and others) get
perfect high DPI support with zero client changes.
Like the window scaling this handles any combination of a 2x scaled
decoration being rendered on a 1x screen or vice versa.
CCBUG: 384765
Test Plan:
export KWIN_COMPOSE=Q
Had two screens of different scales
It was the right size on both (as before)
Was super-sharp on the fancy screen
Reviewers: #plasma, hetzenecker, graesslin
Reviewed By: #plasma, graesslin
Subscribers: ngraham, graesslin, plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8504
Summary:
Not needed except for X11/non-composited usage, so should be in the
plugin instead of core.
Platform API is extended to create a decoration renderer.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7444
Required to stop and disconnect the timer. Otherwise it's possible
that the render is invoked after the Client got destroyed. This
happened for example with e.g. opening Kickoff.
The Renderer gets reparented to the Deleted. While passing it to
the Deleted the Scene's implementation can ensure that the buffers
are up to date. After passing to Deleted it's no longer allowed to
call the render method.
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
David Edmundson
Martin Flöser