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:
Small intermediate refactor. For now just do the normal rotation when a flipped
transform is requested. In the future we might want to provide the possibility
to flip the output image.
Test Plan: Compiles
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25649
Summary:
This change updates the copyright statement and adds a few folks who are
considered to be kwin maintainers.
Test Plan: Compiles.
Reviewers: davidedmundson, romangg
Reviewed By: davidedmundson, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25646
Summary:
We leak memory if we do not destroy the dmabuf implementation on EGL backend
going down.
Also this makes sure everything is cleaned up on shutdown.
FIXED-IN: 5.17.4
BUG: 413637
Test Plan: Compiles, settings change and shutdown ok.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25577
Summary:
Tabs in the Window Decoration KCM look awkward now because the frame is drawing an extra line while the tab bar is also drawing its line.
This patch just slightly alters an existing hack so that the frame's top line can't be seen.
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25582
This backend absolutely does not make sense to use on anything
resembling a "desktop computer" as bshah explained to me. Still, I
somehow have the corresponding optional dependencies installed and
so I triggered the problem.
Reviewed-By: bshah
Summary:
Instead of using Qt::ScreenOrientation use an enum class that is directly
mapped to KWayland's transformation enums. This simplifies the code.
Test Plan: Compiles and transformations work as before.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11670
Differential Revision: https://phabricator.kde.org/D25558
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:
KDE is known for having a strong view on the client-side decorations vs
server-side decorations issue. The main argument raised against CSD is
that desktop will look less consistent when clients start drawing window
decorations by themselves, which is somewhat true. It all ties to how
well each toolkit is integrated with the desktop environment.
KDE doesn't control the desktop market on Linux. Another big "player"
is GNOME. Both KDE and GNOME have very polarized views on in which
direction desktop should move forward. The KDE community is pushing more
toward server-side decorations while the GNOME community is pushing
more toward client-side decorations. Both communities have developed
great applications and it's not rare to see a GNOME application being
used in KDE Plasma. The only problem is that these different views are
not left behind the curtain and our users pay the price. Resizing GTK
clients in Plasma became practically impossible due to resize borders
having small hit area.
When a client draws its window decoration, it's more likely that it also
draws the drop-shadow around the decoration. The compositor must know
the extents of the shadow so things like snapping and so on work as
expected. And here lies the problem... While the xdg-shell protocol has
a way to specify such things, the NetWM spec doesn't have anything like
that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with
it is that it's a proprietary atom, which is specific only to GTK apps.
Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing
anything like that would require major changes in how we think about
geometry.
Recent xdg-shell window geometry patches adjusted geometry abstractions
in kwin to such a degree that it's very easy to add support for client
side decorated clients on X11. We just have to make sure that the
X11Client class provides correct buffer geometry and frame geometry when
the gtk frame extents are set.
Even though the X11 code is feature frozen, I still think it's worth
to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize
issues. Also, because KWin/Wayland is unfortunately far from becoming
default, it will help us with testing some implementation bits of the
window geometry from xdg-shell.
BUG: 390550
FIXED-IN: 5.18.0
Test Plan:
Things like quick tiling, maximizing, tiling scripts and so on work as
expected with GTK clients.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: cblack, trmdi, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24660
Summary:
The stored buffer geometry can be useful for detecting whether the
buffer geometry has been changed.
Test Plan: Compiles.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24659
Summary:
Rename geometryBeforeUpdateBlocking in order to better reflect that it
corresponds to the last frame geometry.
Test Plan: Compiles.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24658
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:
The damage region is in surface-local coordinates, while the repaints
region is in frame-local coordinates, i.e. relative to the top-left
corner of the frame geometry.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24460
Summary:
Frame and buffer geometry don't have strict order. Either one of them can
be inside the other one, so we must take that into account when computing
visible bounds of the client including drop-shadows. We also have to take
sub-surfaces into account when determining the visible rect, however it's
out of scope for this patch.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24458
Summary:
The repaints region is in frame-local coordinates, i.e. relative to the
top-left corner of the frame geometry.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24457
Summary:
So far the window geometry from xdg-shell wasn't implemented as it should
be. A toplevel must have two geometries assigned to it - frame and buffer.
The frame geometry describes bounds of the client excluding server-side
and client-side drop-shadows. The buffer geometry specifies rectangle on
the screen occupied by the main surface.
State and geometry handling in XdgShellClient is still a bit broken. This
change doesn't intend to fix that, it must be done in another patch asap.
Test Plan: New tests pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24455
Summary:
In case of a failed atomic commit the previous mode should be fallen back to.
For orientation provide again a setter that DRM backend can use to set the
transform back to the last working one.
Test Plan: Compiles, fallback works, cursor still messed up somewhat (scaling issue?).
Reviewers: #kwin
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11670
Differential Revision: https://phabricator.kde.org/D25507
Summary:
We use internally Qt:ScreenOrientation for representing output transforms.
This is not ideal since the values do not map directly to Wayland transform
values, but we can make it work by using OR combinations of
Qt:ScreenOrientations.
Do this for now and see if we should not better introduce an internal enum
mapped directly.
Additionally the OR combinations need to be handled in the drm backend at
various places accordingly as well (see TODOs).
Test Plan: Compiles
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T11670
Differential Revision: https://phabricator.kde.org/D25505
Summary:
Move the Wayland output device and output transform calls from DRM backend
to AbstractWaylandOutput. This leaves still some loose ends that need to be
tied up later. On failed commit we want to fall back to last working state
and orientation getter in general needs some more refactoring.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T11670
Differential Revision: https://phabricator.kde.org/D25504
I build kwindowsystem with -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.62.0,
and this broke here. Use the exact same condition as the one around
those virtual methods in the base class.
Same fix as https://phabricator.kde.org/D25488
Summary:
this makes the "no borders" option do something: however it cause many
other issues with many themes that weren't really designed for "no
borders"
it fixes the "tiny borders" for almost all themes, as the whole calculation before
was
completely wrong
Test Plan:
Some themes work way better now, some look broken with no border or no side borders
some look perfect with those options
another issue is that aurorae is going to support no borders, it has to support like
breeze resizing from the shadows
Reviewers: #plasma, #kwin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: davidedmundson, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25146
Summary:
If an effect renders a window into an offscreen texture, it's very important
that the window ends up in the offscreen render target rather than the default
framebuffer object. However, that might be not the case if the OpenGL
decoration renderer needs to create a texture atlas since the renderer calls
GLTexture::clear() method, which might clobber the current GL_DRAW_FRAMEBUFFER
binding.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25365
Summary: TabBoxClient::window() method is no longer used by the tabbox.
Test Plan: Compiles, tests still pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25092
