Things such as Output, InputDevice and so on are made to be
multi-purpose. In order to make this separation more clear, this change
moves that code in the core directory. Some things still link to the
abstraction level above (kwin), they can be tackled in future refactors.
Ideally code in core/ should depend either on other code in core/ or
system libs.
This change adjusts the window management abstractions in kwin for the
drm backend providing more than just "desktop" outputs.
Besides that, it has other potential benefits - for example, the
Workspace could start managing allocation of the placeholder output by
itself, thus leading to some simplifications in the drm backend. Another
is that it lets us move wayland code from the drm backend.
With fractional scaling integer based logical geometry may not match
device pixels. Once we have a floating point base we can fix that. This
also is
important for our X11 scale override, with a scale of 2 we could
get logical sizes with halves.
We already have all input being floating point, this doubles down on it
for all remaining geometry.
- Outputs remain integer to ensure that any screen on the right remains
aligned.
- Placement also remains integer based for now.
- Repainting is untouched as we always expand outwards
(QRectF::toAdjustedRect().
- Decoration is untouched for now
- Rules are integer in the config, but floating in the adjusting/API
This should also be fine.
At some point we'll add a method to snap to the device pixel
grid. Effectively `round(value * dpr) / dpr` though right now things
mostly work.
This also gets rid of a lot of hacks for QRect right and bottom which
are very
confusing.
Parts to watch out in the port are:
QRectF::contains now includes edges
QRectF::right and bottom are now sane so previous hacks have to be
removed
QRectF(QPoint, QPoint) behaves differently for the same reason
QRectF::center too
In test results some adjusted values which are the result of
QRect.center because using QRectF's center should behave the same to the
user.
The guessed repaint region is not optimal on wayland. Second, if it's a
new output, it's expected that there will be already a scene repaint
that covers all items on the given output so items don't need to provide
redundant repaint region.
Conceptually, scheduling repainting in Window doesn't belong there. This
change rewires EffectWindow internals so it schedules repaints using the
associated WindowItem.
Window::addWorkspaceRepaint() has not been removed yet because
Window::elevate() uses it.
This change makes the WindowItem track the opacity and schedule a
repaint. It further decouples the legacy scene from code window
abstractions.
It's an API breaking change. WindowPaintData no longer can make windows
more opaque. It only provides additional opacity factor.
Item::isVisible() is true if either the item has been marked hidden or
one of its ancestors.
In some cases, kwin may render invisible windows, for example for window
thumbnails.
This change makes rendering code use explicit visibility status when
rendering to ensure that it's still possible to render invisible windows.
AbstractOutput is not so Abstract and it's common to avoid the word
"Abstract" in class names as it doesn't contribute any new information.
It also significantly reduces the line width in some places.
At this point, it's safe to assume that only X11 has weird rendering
model, which stands in the way of making rendering abstractions nice and
intuitive, so let's check operation mode. If OperationModeX11 is
dropped, this will also simplify finding X11-specific code in kwin.
Having a render loop in the Platform has always been awkward. Another
way to interpret the platform not supporting per screen rendering would
be that all outputs share the same render loop.
On X11, Scene::painted_screen is going to correspond to the primary
screen, we should not rely on this assumption though!
The Compositor contains nothing that can potentially get dirty and need
repainting.
As is, the advantages of this move aren't really noticeable, but it
makes sense with multiple scenes.
Backend parts are far from ideal, they can be improved later on as we
progress with the scene redesign.
With an opaque fullscreen window we can be sure that items under it don't
actually require us to repaint. This should yield some small efficiency
improvements and resolves stutter with adaptive sync.
BUG: 443872
FIXED-IN: 5.23.3
The bounding rect of an item is in the item-local coordinate space. If
the item is moved, its bounding rect won't change, but the parent's
bounding rect, may change.
BUG: 443756
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.
Currently, a vertex coordinate is transformed first, then mapped to
the global screen coordinates. This causes a problem if a transform
is applied to the top-most item and child items are not at (0, 0).
For example, scaled windows may have popping out sub-surfaces, etc.
With this change, the item transforms will be computed differently. For
example, if the parent item is transformed, a child's transform will
look as follows
[Parent's translation][Parent's transform][Child's translation]
instead of
[Parent's translation][Child's translation][Parent's transform]
In the future, I'd like to get rid of the Item::setTransform() call in
OpenGLWindow::performPaint() and have either AnimationEffect or
libkwineffects call Item::setTransform().
BUG: 440201
According to the spec, if the wl_subsurface.place_below request is
called with the parent surface, the sub-surface must be placed below the
parent surface.
BUG: 438808
Originally, only x, y, width, and height property setters were used. A
bit later "position" and "size" helper setters were added to simplify
code in SurfaceItem sub-classes. It seems like setX(), setY(), setWidth(),
and setHeight() are unused now, so remove them.
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.
One can think that Item::scheduleRepaint() will trigger repaint of the
whole item, but it actually only schedules the next frame. If nothing
has changed on the screen, no real painting will be done unless maybe if
the rendering backend needs to repair the back buffer.
Currently, items depend on scene windows for creating pixmaps, repaint
scheduling, and caching quads.
This change moves repaint scheduling from scene windows to items to
make the scene items depend less on scene windows.
In hindsight, we may clean up the repaint scheduling machinery further
by introducing view objects.
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.
