Commit graph

14 commits

Author SHA1 Message Date
Vlad Zahorodnii
bb935aa5de Fix decoration rendering with scale factor < 1
QPainter won't let paint with a device pixel ratio less than 1. There
are used to be workarounds to force a device pixel ratio of 1, but they
were removed with fractional scaling corner fix.

This change makes sure that the decoration renderer forces a device
pixel ratio of 1 if the output's scale factor is less than 1 so
calculated texture coordinates match where window borders are rendered
in the texture atlas.

BUG: 449681
2022-02-07 11:45:31 +00:00
Vlad Zahorodnii
e2a393ce2d Move utils.h file to utils directory 2022-01-25 16:56:33 +00:00
Julius Zint
3b4d558371 Improve window decorations in OpenGL scene
When creating the texture containing the window decorations, the drawing
code now directly handles the rotation for the left and right
decoration, instead of rotating the image after it has been drawn.

The padding, to prevent texture bleeding, is now a fixed value instead
of being scaled. With this change, there are no longer visual artifacts
for window decorations with rounded corners, when the scaling value is
fractional.
2021-12-30 09:07:42 +00:00
Vlad Zahorodnii
cbad78a360 Kill Toplevel::screenScale()
Tracking AbstractOutput properties in Toplevel is not extensible. Since
DecorationItem is the only one who needs Toplevel::screenScale(), make
it track the output device pixel ratio.
2021-11-29 13:14:01 +00:00
Aleix Pol
b44f33c7ed DecorationItem: Prevent crash
We are calling a QPointer without checking it first.
2021-11-08 13:35:03 +00:00
Vlad Zahorodnii
7e9c6587db Remove scene window traces in scene items
This further decouples scene items from scene windows. The SurfaceItem
still needs to access the underlying window, I would like to re-iterate
over that later.

With this change, it will be possible to introduce WindowItem factory
function in the Toplevel class.
2021-08-12 17:52:24 +00:00
Vlad Zahorodnii
ad4f183a76 x11: Drop support for _NET_WM_FRAME_OVERLAP
The main idea behind _NET_WM_FRAME_OVERLAP is to extend the borders of
the server-side decoration so the application can draw on top of it. It
was inspired by similar feature in Windows.

However, _NET_WM_FRAME_OVERLAP is basically unused. Neither GTK nor Qt
support it and I have never seen any application that uses it.

At the moment, kwin is the only compositing window manager that supports
_NET_WM_FRAME_OVERLAP. Neither mutter nor compiz nor compton and so on
support it.

Since _NET_WM_FRAME_OVERLAP is practically unused, there's no point for
keeping supporting it.

This change shouldn't affect any existing app as _NET_WM_FRAME_OVERLAP
atom is not listed in _NET_SUPPORTED.
2021-08-12 11:44:40 +00:00
Vlad Zahorodnii
c6ffdf4f7f kwineffects: Remove WindowQuad::uvAxisSwapped
Since makeSubQuad() uses bilinear interpolation, the flag to indicate
whether UV-coordinates are swapped is redundant.
2021-07-04 16:12:06 +00:00
Vlad Zahorodnii
49744cfc53 scene: Improve window quad management
At the moment, we handle window quads inefficiently. Window quads from
all items are merged into a single list just to be broken up again.

This change removes window quads from libkwineffects. This allows us to
handle window quads efficiently. Furthermore, we could optimize methods
such as WindowVertex::left() and so on. KWin spends reasonable amount
of time in those methods when many windows have to be composited.

It's a necessary prerequisite for making wl_surface painting code role
agnostic.
2021-06-14 07:56:02 +00:00
Vlad Zahorodnii
29cc319455 kwineffects: Remove WindowQuadType
The window quad type has become irrelevant.
2021-06-14 07:56:02 +00:00
Vlad Zahorodnii
86bb4e68ef Refactor window quad handling
The scene items depend on the scene windows for caching window quads.
The goal of this change is to move window quads management to item.

Merging window quads in one list and then splitting them is inefficient,
it will be highly desirable if window quads are removed from the public
api so we can optimize window quad management.

With this change, the window quad type becomes irrelevant to render
backends for the most part. Note that the Xrender backend is a bit
nitpicky about window quads, so the shadow item doesn't create generic
"WindowQuadShadow" quads anymore.
2021-06-11 06:03:08 +00:00
Vlad Zahorodnii
1b2c7b248b Run clazy with qt-keywords fixit
In C++20, there will be emit() class member, which can conflict with the
emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by
default in the future.

See also
https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 10:49:42 +03:00
Vlad Zahorodnii
f46c7bae8d Move decoration renderer to decoration item
Currently, the implementation of the DecoratedClient and the decoration
renderer are strongly coupled. This poses a problem with the item based
design as the ultimate goal is to have scene items construct paint nodes
which are then fed to the renderer. The DecorationItem has to have
control over the decoration texture. Another issue is that the scene
cannot smoothly cross-fade between two window states if the decoration
is removed, e.g. from fullscreen mode to normal and vice versa.

This change moves the decoration renderer to the decoration item. With
the introduction of a generic scene texture atlas, we hope to get rid of
the decoration renderer altogether.
2021-05-26 06:35:03 +00:00
Vlad Zahorodnii
47113e09b8 scene: Introduce window items
Currently, dealing with sub-surfaces is very difficult due to the scene
design being heavily influenced by X11 requirements.

The goal of this change is to re-work scene abstractions to make improving
the wayland support easier.

The Item class is based on the QQuickItem class. My hope is that one day
we will be able to transition to QtQuick for painting scene, but in
meanwhile it makes more sense to have a minimalistic internal item class.

The WindowItem class represents a window. The SurfaceItem class represents
the contents of either an X11, or a Wayland, or an internal surface. The
DecorationItem and the ShadowItem class represent the server-side deco and
drop-shadow, respectively.

At the moment, the SurfaceItem is bound to the scene window, but the long
term plan is to break that connection so we could re-use the SurfaceItem
for things such as software cursors and drag-and-drop additional icons.

One of the responsibilities of the Item is to schedule repaints as needed.
Ideally, there shouldn't be any addRepaint() calls in the core code. The
Item class schedules repaints on geometry updates. In the future, it also
has to request an update if its opacity or visibility changes.
2021-03-31 13:56:55 +00:00