Summary: Don't include the \n at the end of the debug messages
Test Plan: Now I can see the debug errors without an empty line below
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29684
No window quads are generated for sub-surfaces right now. This leads to
issues with effects that operate on window quads, e.g. magic lamp and
wobbly windows. Furthermore, the OpenGL scene needs window quads to
properly clip windows during the rendering process.
The best way to render sub-surfaces would be with a little help from a
scene graph. Contrary to GNOME, KDE hasn't developed any scene graph
implementation that we could use in kwin. As a short term solution, this
change adjusts the scene to generate window quads.
Window quads are generated as we traverse the current window pixmap tree
in the depth-first search manner. In order to match a list of quads with
a particular WindowPixmap, we assign an id to each quad.
BUG: 387313
FIXED-IN: 5.19.0
Differential Revision: https://phabricator.kde.org/D29131
In order to generate window quads for sub-surfaces, we need a valid
window pixmap tree. The problem is that the window pixmap tree is
created too late in the rendering process. This change adjusts the
scene so it creates window pixmap trees before buildQuads().
Differential Revision: https://phabricator.kde.org/D29131
Summary:
The screenshot made on screens with scale factor were downscaled by their scale factor making them blurry.
It prevents taking screenshots of missing Hidpi related bugs showing the issues under Wayland.
This fix the case of a single screenshot, but not the rest:
Multiscreen screenshot downscales the screen using scale factor.
Spectacle rectangular selection screenshot is broken as soon as some scale factor different than 1 is used on any screen.
Test Plan:
Under Wayland with a scale factor on a screen, take a screenshot using spectacle.
The output image is not downscaled and has the same size as the screen resolution.
No other change to any other screenshot mode, or under X.
Reviewers: davidedmundson, #kwin
Reviewed By: davidedmundson, #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29010
Summary:
As is KWin only had 1 Cursor which was a singleton. This made it impossible for
us to properly implement the tablet (as in drawing tablets) support and show where
we're drawing.
This patch makes it possible to have different Cursors in KWin, it makes all the
current code still follow the mouse but the tablet can still render a cursor.
Test Plan: Tests pass, been using it and works as well as before but with beautiful tablet cursors.
Reviewers: #kwin, cblack, davidedmundson
Reviewed By: #kwin, cblack, davidedmundson
Subscribers: davidedmundson, cblack, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28155
Summary:
This may help with debugging why compositing is suspended.
CCBUG: 418951
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28139
Summary: No need to keep them around for no reason.
Test Plan: Tested the plugins I thought could be affected. Have been using it for a couple of days without problems
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28062
Summary:
This will save the copy of some objects, especially PaintData classes that are
not copy-on-write.
It also follows the practice on other parts of the system.
Test Plan: Running it right now
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28031
Summary:
Otherwise the content overflows the frame when scrolling.
QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true"
Test Plan:
Before:
{F8121150}
After:
{F8121152}
Reviewers: #kwin, #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27558
Summary:
Otherwise the content overflows the frame when scrolling.
QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true"
Test Plan:
Before:
{F8121150}
After:
{F8121152}
Reviewers: #kwin, #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27558
Summary:
If a client has been resized, it doesn't necessarily mean that the
decoration theme will schedule full repaint of the window frame. In
OpenGL and Xrender scene, we have a little hack that forces a full
repaint of window borders. However, we don't have one in QPainter
scene which causes all sorts of weird looking artifacts when resizing
a server-side decorated client.
We could add yet another hack in the QPainter scene, but a better
approach to tackle this problem would be to make DecoratedClient
schedule a full repaint of the decoration. It makes code in scene
plugins more straightforward and prevents us from repeating the same
mistake again.
Test Plan:
No longer able to see invisible decoration borders when
using QPainter render backend.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26927
Summary:
Prefer qobject_cast<> over Toplevel::isClient() because it's more type
safer and makes code a bit more readable.
Hopefully, one day we will be able to get rid of isClient() altogether.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26541
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:
The buffer shape is in buffer-local coordinates and must be mapped to
window coordinates. After that, we are free to map it to the global screen
coordinates.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25733
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:
There's no point for calling discardShape from the destructor of a
Scene::Window subclass because window quads cache will be destroyed
automagically by QScopedPointer.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24317
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
We have lots of inconsistency at the moment in CMakeLists.txt files. Most
of it is due to kwin being a very old project. This change hopefully fixes
all of it.
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:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.
The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.
Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.
A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!
The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.
The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, apol, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22371
Summary:
QImage::byteCount() was deprecated in Qt 5.10. It is advised to use
QImage::sizeInBytes() method instead.
Reviewers: #kwin, apol
Reviewed By: apol
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22355
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:
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:
Lanczos filter shouldn't be in KWin core because it's quite specific about
rendering backend.
Test Plan: Windows in the desktop grid look normal.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: mart, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18774
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:
QPainter doesn't render decoration shadows. It renders only
shadows provided through ShadowInterface.
With this change, painting of shadows is done in similar way OpenGL backend is
currently doing.
Before
{F5734867, layout=center, size=full}
After
{F5734870, layout=center, size=full}
Depends on D10811 (dummy decoration with shadows in autotests)
Test Plan:
* start kwin with QPainter backend enabled:
```
KWIN_COMPOSE=Q kwin_wayland --xwayland --windowed
```
* open konsole and kate:
```
DISPLAY=:1 konsole
DISPLAY=:1 kate
```
Reviewers: #kwin, graesslin, davidedmundson
Reviewed By: davidedmundson
Subscribers: abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D10943
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
