Summary:
Legacy OpenGL 1 compositing backend had been dropped quite a while ago
so some of OpenGL scene classes can be merged back.
Test Plan: Compiles, windows are rendered as before.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26700
Summary:
Scene opengl has a callback for when we have a GL error. One of the
handlers for an error calls scheduleVboReInit the history shows it was a
forerunner to the GLX_NV_robustness_video_memory_purge but resetting
only one tiny part based on debug output.
When we get here we schedule a reset of the vertex buffer, via a timer.
When the timer is caled we have no idea what GL context was last
current, if it's not the currect context then the main scene
GLVertexBuffer will be deleted but not correctly re-initialised.
We have two very common crashes with a corrupted
GLVertexBuffer::streamingBuffer() which would match up perfectly.
Given that we now have a proper mechanism to reset the entire scene, we
don't need this timer based hack and resolve that problem.
BUG: 399499
BUG: 372305
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26556
Summary:
Quite long time ago, window decorations were painted on real X11 windows.
The nicest thing about that approach is that we get both contents of the
client and the frame window at the same time. However, somewhere around
KDE 4.2 - 4.3 times, decoration rendering architecture had been changed
to what we have now.
I've mentioned the previous decoration rendering design because it didn't
have a problem that the new design has, namely the texture bleeding issue.
In the name of better performance, opengl scene puts all decoration parts
to an atlas. This is totally reasonable, however we must be super cautious
about things such as the GL_LINEAR filter.
The GL_LINEAR filter may need to sample a couple of neighboring texels
in order to produce the final texel value. However, since all decoration
parts now live in a single texture, we have to make sure that we don't
sample texels that belong to another decoration part.
This patch fixes the texture bleeding problem by padding each individual
decoration part in the atlas. There is another solution for this problem
though. We could render a window into an offscreen texture and then map
that texture on the transformed window geometry. This would work well and
we definitely need an offscreen rendering path in the opengl scene,
however it's not feasible at the moment since we need to break the window
quads API. Also, it would be great to have as less as possible stuff going
on between invocation of Scene::Window::performPaint() and getting the
corresponding pixel data on the screen.
There is a good chance that the new padding stuff may make you vomit. If
it does so, I'm all ears for the suggestions how to make the code more
nicer.
BUG: 257566
BUG: 360549
CCBUG: 412573
FIXED-IN: 5.18.0
Reviewers: #kwin
Subscribers: fredrik, kwin, fvogt
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25611
Summary:
We currently see a gap on transformed windows between the window and the
top decoration.
This is partly the atlas bleed on the decoration, and partly a bleed on
the window content itself.
On X11, the window we composite is the frame window - which is a larger
texture containing a transparent border where the frame normally would
be. When we sample with a linear filter we include these texels. Hence
GL_CLAMP_TO_EDGE doesn't work.
Vlad's patch to composite the correct window, not the frame was my
preferred approach, but we had to revert it as it caused an issue with
xwayland :(
Half pixel correction nearly worked, but caused blurry fonts.
This patch resolves it in the fragment shader used by effects doing
transforms. We pass the real texture geometry of the window to the
client with a half pixel correction. Any samples outside the outer half
pixel are then clamped within bounds.
Arguably a hack, but solves the problem in a comparatively
non-invasive way.
BUG: 360549
BUG: 257566
Test Plan:
X11:
Using Vlad's atlas padding for decoration
Slowed animations, wobbled a dark window over a light background
No artifacts
Wayland:
This isn't needed. Now tested that everything still renders the same.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, jgrulich, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25737
Summary:
Add a small getter to query information internally if the backend supports
swap events. Defaults to true as it is the default in the GBM Wayland backend.
Test Plan: i915
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D25298
Summary:
According to Gl 3.2 (page 501) and 4.5 (page 204) specs the initial state of
the default framebuffer is already BACK. Therefore we do not need to set it
explicitly.
When we draw in the future to alternative framebuffers which do not have back
buffers this call is fatal.
Test Plan: No tearing on Wayland, tearing as before on X11.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25868
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:
Quite long time ago, window decorations were painted on real X11 windows.
The nicest thing about that approach is that we get both contents of the
client and the frame window at the same time. However, somewhere around
KDE 4.2 - 4.3 times, decoration rendering architecture had been changed
to what we have now.
I've mentioned the previous decoration rendering design because it didn't
have a problem that the new design has, namely the texture bleeding issue.
In the name of better performance, opengl scene puts all decoration parts
to an atlas. This is totally reasonable, however we must be super cautious
about things such as the GL_LINEAR filter.
The GL_LINEAR filter may need to sample a couple of neighboring texels
in order to produce the final texel value. However, since all decoration
parts now live in a single texture, we have to make sure that we don't
sample texels that belong to another decoration part.
This patch fixes the texture bleeding problem by padding each individual
decoration part in the atlas. There is another solution for this problem
though. We could render a window into an offscreen texture and then map
that texture on the transformed window geometry. This would work well and
we definitely need an offscreen rendering path in the opengl scene,
however it's not feasible at the moment since we need to break the window
quads API. Also, it would be great to have as less as possible stuff going
on between invocation of Scene::Window::performPaint() and getting the
corresponding pixel data on the screen.
There is a good chance that the new padding stuff may make you vomit. If
it does so, I'm all ears for the suggestions how to make the code more
nicer.
BUG: 257566
BUG: 360549
CCBUG: 412573
FIXED-IN: 5.18.0
Reviewers: #kwin
Subscribers: fredrik, kwin, fvogt
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25611
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:
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:
Compositing in X11 was done time shifted, meaning that we paint first, then
wait one vblank interval length and present on prepareRenderingFrame the
previous paint result. This is supposed to make sure we don't miss the vblank
and in case of block till retrace be able to continue issuing commands and
only shortly before next vblank present.
This is counter-intuitiv, not how we do it on Wayland or even on MESA with X.
The reason seems to be that the GLX backend was in the beginning written
against Nvidia proprietary driver which needed this but nowadays even this
driver defaults to non-blocking behavior on buffer swap.
Therefore remove this legacy anomaly fully and directly present after paint.
We then wait one refresh cycle and in the future can optimize this by delaying
the paint and present till shortly before vsync.
Test Plan: kwin_x11 tested on i915 and Nvidia proprietary driver.
Reviewers: #kwin
Subscribers: zzag, alexeymin, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D23514
Summary:
Selecting not to vsync does not make sense for an X11 compositor. In the end
we want clients to be able to present async if they want to but the compositor
is supposed to send swaps with vsync to the XServer in order to not generate
tearing artifacts.
There was also a detection logic which did some questionable things in case
vsync was not available. I don't think this is necessary at all since we can
just always run a timer to present with or without vsync.
Test Plan: kwin_x11 tested on i915.
Reviewers: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D23511
Summary:
Everything is already multiplied in the buffer, we want to copy the
source directly.
Test Plan:
Looked at something with EffectQuickView and alpha
It now matched what it should be
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24368
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:
EffectQuickView/Scene is a convenient class to render a QtQuick
scenegraph into an effect.
Current methods (such as present windows) involve creating an underlying
platform window which is expensive, causes a headache to filter out
again in the rest of the code, and only works as an overlay.
The new class exposes things more natively to an effect where we don't
mess with real windows, we can perform the painting anywhere in the view
and we don't have issues with hiding/closing.
QtQuick has both software and hardware accelerated modes, and kwin also
has 3 render backends. Every combination is supported.
* When used in OpenGL mode for both, we render into an FBO export the
texture ID then it's up to the effect to render that into a scene.
* When using software QtQuick rendering we blit into an image, upload
that into a KWinGLTexture which serves as an abstraction layer and
render that into the scene.
* When using GL for QtQuick and XRender/QPainter in kwin everything is
rendered into the internal FBO, blit and exported as an image.
* When using software rendering for both an image gets passed directly.
Mouse and keyboard events can be forwarded, only if the effect
intercepts them.
The class is meant to be generic enough that we can remove all the
QtQuick code from Aurorae.
The intention is also to replace EffectFrameImpl using this backend and
we can kill all of the EffectFrame code throughout the scenes.
The close button in present windows will also be ported to this,
simplifiying that code base.
Classes that handle the rendering and handling QML are intentionally
split so that in the future we can have a declarative effects API create
overlays from within the same context. Similar to how one can
instantiate windows from a typical QML scene.
Notes:
I don't like how I pass the kwin GL context from the backends into the
effect, but I need something that works with the library separation. It
also currently has wayland problem if I create a QOpenGLContext before
the QPA is set up with a scene - but I don't have anything better?
I know for the EffectFrame we need an API to push things through the
effects stack to handle blur/invert etc. Will deal with that when we
port the EffectFrame.
Test Plan: Used in an effect
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24215
Summary:
Qt's metaobject is rather sensitive with scope resolution.
Foo::Bar and Bar don't always match to a Qt metaobject, even if they
refer to the same thing to a compiler. Here we register
X11Compositor::SuspendReason but Q_ARG uses SuspendReason and they don't
match. This leads to a runtime failure where the method isn't invoked.
Rather than fixing metaobject usage, port the whole thing to lambdas
which does better compile time checking and is generally nicer to read.
BUG: 412353
Test Plan:
Ran xprop to block compositing. Compositing was blocked.
Grepped source code for Q_ARG use
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24244
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:
With nearest filter fractional scaling is blurry, always use linear filter
instead on Wayland.
Test Plan: Run Plasma session with patch and scale factor 1.9.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T10481
Differential Revision: https://phabricator.kde.org/D23986
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:
This patch is a first take at splitting up of the Compositor class into
Wayland and X11 child classes.
In this first patch we mostly deal with setup and teardown procedures.
A future goal is to further differentiate the compositing part itself too.
Test Plan: Manually X from VT and Wayland nested. Autotests pass.
Reviewers: #kwin
Subscribers: sbergeron, anthonyfieroni, zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D22195
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:
kwin(28512) QPainter::begin|QPainter::QPainter|KWin::Decoration::Renderer::renderToImage QPainter::begin: Paint device returned engine == 0, type: 3
kwin(28512) QPainter::setRenderHints|QPainter::setRenderHint|KWin::Decoration::Renderer::renderToImage QPainter::setRenderHint: Painter must be active to set rendering hints
kwin(28512) QPainter::setWindow|KWin::Decoration::Renderer::renderToImage|?KWinX11Platform.so? QPainter::setWindow: Painter not active
kwin(28512) QPainter::setClipRect|KWin::Decoration::Renderer::renderToImage|?KWinX11Platform.so? QPainter::setClipRect: Painter not active
Test Plan: seems to happen on startup, at least (when restarting kwin)
Reviewers: graesslin, zzag
Reviewed By: zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9014
Summary:
If hardware cursor support is not available when using the drm backend for
Wayland compositing, the software cursor texture will not be updated when the
cursor image changes, and it will still be drawn when no cursor image is set
(such as when running a full-screen game). Furthermore, the drmModeSetCursor
and drmModeMoveCursor functions will still be unnecessarily called when the
cursor is moved or hidden.
To correct this, SceneOpenGL should connect Platform::cursorChanged as opposed
to Cursor::cursorChanged to its texture update function, as only the former
will be emitted when the cursor is updated and the compositor should check if
the cursor is hidden and the software cursor image is not null before rendering
it. DrmBackend::moveCursor and DrmBackend::hideCursor should also return
immediately if using a software cursor.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18376
Summary:
Deleted has lifetime bounded to effects and scene.
We can't discard Deleted before EffectsHandler is destroyed because
effects that referenced it may call unrefWindow.
On the other hand, the fact that Deleted may outlive scene doesn't
make sense because Deleted exist purely for animation purposes and
nothing more.
This change arranges lifetime of Deleted so it's more reasonable.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18914
Summary:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
Summary:
Currently, when the lanczos filter attempts to release acquired resources,
the backend is already gone. To fix that we have to destroy the filter
together with SceneOpenGL2. At that moment the backend is still alive.
BUG: 403370
FIXED-IN: 5.15.0
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18367
Summary:
When suspending compositing, SceneOpenGLShadow cannot cleanup cached
decoration shadow textures because the effects handler is already gone.
This sometimes can result in a crash when running kwin_x11 --replace
(we're hitting an assert statement).
To fix that, let's use the scene instead of the effects handler for
making the OpenGL context current.
Test Plan:
No longer hit the assert statement:
ASSERT: "m_cache.isEmpty()" in file /home/vlad/Workspace/KDE/src/kde/workspace/kwin/plugins/scenes/opengl/scene_opengl.cpp, line 2025
Application::crashHandler() called with signal 6; recent crashes: 1
QCoreApplication::applicationFilePath: Please instantiate the QApplication object first
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kwin_x11 path = /home/vlad/Workspace/KDE/usr/bin pid = 5407
KCrash: Arguments: /home/vlad/Workspace/KDE/usr/bin/kwin_x11 --replace
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17306
Summary:
The idea of opening the compositing kcm was to show a warning. But that
broke quite some time ago without noticing. We had two ways:
* pass through --args command line argument
* use dbus call to already open kcm
Neither of the two ways is working. The kwincompositing doesn't parse
the arguments and the dbus interface doesn't exist any more.
Following the advice to remove functionality nobody noticed that it is
broken, this is removed with this change. This probably broke with
introducing the new KCM which happened IIRC for Plasma 5.0.
BUG: 393845
FIXED-IN: 5.14.0
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13235
Summary:
If the corner shadow tiles(top-left, top-right, and so on) tiles are missing,
then the left/top/right/bottom shadow tiles will overlap.
This diff addresses that problem by changing how the shadow texture
atlas is rendered:
* corner tiles will be drawn in the corners of the atlas(buildQuads
method expects them to be at the corners);
* top, right, bottom, and left tile will be aligned to the top-left
corner of the inner shadow rect.
For majority of desktop themes, the shadow texture atlas looks the same.
For example, here's for Aether:
Before:
{F6190484, layout=center, size=full}
After:
{F6190488, layout=center, size=full}
Depends on D14783
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14784
Summary:
Current implementation of buildQuads assumes that corner shadow tiles
are always present:
const QRectF leftRect(
topLeftRect.bottomLeft(),
bottomLeftRect.topRight());
but that assumption is wrong. For example, if the default panel is on
the bottom screen edge, then the calendar popup won't have the
bottom-left shadow tile(at least on Wayland). Which means that the left
shadow tile won't be visible because
topLeftRect.left() == bottomLeftRect.right().
Corner rectangles only have to influence height of the left/right tile
and width of the top/bottom tile. Width of the left/right tile and
height of the top/bottom tile should not be controlled by corner tiles.
Overall, this is how shadow quads are computed:
* Compute the outer rectangle;
* Compute target rectangle for each corner tile. If some corner tile is
missing, move the target rectangle to the corresponding corner of the
inner shadow rect and set its width and height to 0. We need to do
that to prevent top/right/bottom/left tiles from spanning over
corners:
{F6190219, layout=center, size=full}
We would rather prefer something like this if the top-left tile is
missing:
{F6190233, layout=center, size=full}
* Fix overlaps between corner tiles;
* Compute target rectangles for top, right, bottom, and left tiles;
* Fix overlaps between left/right and top/bottom shadow tiles.
Test Plan:
* Ran tests;
* Resized Konsole to its minimimum size(on X11 and Wayland);
* Opened the calendar popup(on X11 and Wayland):
Before:
{F6190344, layout=center, size=full}
After:
{F6190346, layout=center, size=full}
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: abetts, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14783
Summary:
This problem appears if shadow corner tiles are too big and
some window has size smaller than 2 * shadowTileSize.
This change tries to address the problem above by exclusing
overlapping tile parts. If there are any two overlapping corners
then tile between them(top/right/bottom/left) is not rendered.
Also, because some corner tile parts can be excluded, corner tiles
are expected to be symmetrical(i.e. if we remove right half from
the top-left tile and left half from the top-right tile and
stick them together, they still look fine, there are no misalignments, etc).
Most shadows(e.g. shadows from Breeze) have such behaviour.
No tiles are overlapping
{F5728514, layout=center, size=full}
Overlapping tiles
{F5728516, layout=center, size=full}
And this is how it supposed to be
{F5728517, layout=center, size=full}
Test Plan:
* apply D11069 to Breeze
* in System Settings/Application Style/Window Decorations, choose "Very Large" shadow size
* open Konsole
* resize it to a minimum possible size
Reviewers: #kwin, graesslin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, ngraham, anemeth, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D10811
Summary:
While investigating BUG 387313 I noticed that blending might be disabled
for subsurfaces. Blending was disabled before rendering the subsurfaces
and it is not checked whether the surfaces have an alpha channel or not.
This change addresses this problem by disabling blending after all
subsurfaces have been rendered and enabling blending if a subsurface has
an alpha channel.
Unfortunately this does not fix the investigated bug.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10060
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:
With the new try of all compositor types supported there is an automatic
fallback from OpenGL to XRender/QPainter in case OpenGL setup failed.
So there is no need to invoke a method to do just that.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8364
