We currently deal with three distinct coordinate spaces - the window
pixmap coordinate space, the window coordinate space, and the buffer
pixel coordinate space.
This change introduces a couple of helper methods to make it easier
to map points from the window pixmap space to the other two spaces.
The main motivation behind the new helpers is to break the direct
relationship between the surface-local coordinates and buffer pixel
coordinates for wayland surfaces.
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
Aleix Pol