Currently when we move the mouse the one render loop triggers a repaint.
When the cursor layer needs a new update we end up in the compositor
repainting the main content.
Even though painting should mostly no-op it still goes through all
existing items and effects to collect damage, still potentially making
the GL context current which could stall. A waste when we know we
haven't got anything to do. It's enough to cause noticable mouse lag on
some hardware.
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
It never belonged in the OutputBackend, but we also didn't have a better
place when the relevant code had been added.
With the introduction of graphics buffer allocators, it's no longer the
case.
The buffer transform specifies a transform from the buffer coordinate
space to the surface coordinate space.
The inverse buffer transform specifies a transform from the surface
coordinate space to the buffer coordinate space.
OutputTransform::map(QRect, QSizeF) expects both arguments to be in the
same coordinate space.
In case of SurfaceInterfacePrivate::computeSourceBox(), both should be
scaled surface coordinates so bufferTransform.inverted() maps the source
rect to the proper buffer coordinate space.
Instead of hardcoding ARGB8888 and using implicit modifiers, look through
the list of available formats and modifiers and pick a match that egl will
actually accept.
In some cases, it's desired to know what the inverse transform of a
given output transform is. It's possible to make it work by providing
helper functions, but we tend to avoid doing so.
This change converts the OutputTransform from an enum to a class so it's
possible to have both data + methods in the same type. Unfortunately,
unlike Rust, C++ provides no way to attach methods to enums, classes and
structs is the only way to go.
Being in the KWin namespace has a couple of advantages: the enum can be
forward declared, and the transform can be replaced with a slightly more
complex but useful type.
If the surface item's contents is scaled, i.e. its scale factor doesn't
match the output's scale, GL_LINEAR will be applied to smooth the
contents. The unfortunate thing is that it's possible some of the
changed pixels will bleed to the neighbor ones.
In order to handle that scenario better, this change makes the
SurfaceItem expand the damage if there's scale factor mismatch.
bufferSourceBox and bufferTransform properties were introduced to detect
if the surface contents is going to be scaled. bufferSourceBox covers
both crop transform from wp_viewport and scale factor from wl_surface.
bufferTransform is same as wl_surface's buffer transform property.
The bufferSourceBox provides a way to get the source region of the
attached buffer. It can be used to compute the effective scale factor
when using wp_viewport.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
If a gbm_bo is allocated with GBM_BO_USE_WRITE, it will be backed by a
dumb buffer under the hood. However, it seems like neither gbm_bo_get_fd()
nor gbm_bo_get_plane_fd() would return valid file descriptors, which are
required to fill in DmaBufAttributes.
As an interim solution, this change makes the GbmGraphicsBufferAllocator
allocate dumb buffers on its own rather than delegate it to gbm.
This change ports the drm backend to the GraphicsBuffer and
GraphicsBufferAllocator.
The main motivation is to unify graphics buffer abstractions across
various backends and to prepare it for output layers, which could be
nicer if we could have direct control over the buffers.
The drm backend needs to allocate both dmabuf and dumb buffers, for
example for multi-gpu import.
Allowing GbmGraphicsBufferAllocator to allocate dumb buffers allows us
to avoid using several buffer allocators in the drm backend.
The software flag indicates whether the graphics buffer allocator needs
to allocate a buffer suitable for software rendering. Its intended usage
is to allow the gbm allocator to allocate both dmabuf and dumb buffers.
This is done by converting from the sRGB + gamma 2.2 input from clients
to linear with the color space of the output (BT.709 or BT2020 atm) in
a shadow buffer, and then convert from the shadow buffer to the transfer
function the output needs (sRGB or PQ).
When GraphicsBuffer::dropped() is emitted, the buffer can be
unreferenced. If that's the case, the GraphicsBuffer will be deleted
twice: first in GraphicsBuffer::unref(), the second time in drop().
In order to address the issue, this change gets rid of the
GraphicsBuffer::dropped() signal, so it's always guaranteed that the
buffer stays alive until the reference count is checked.
The GraphicsBuffer::dropped() signal is used to remove the mapping
between wl_resource and ShmClientBuffer when the corresponding
wl_shm_buffer object is destroyed. On the other hand, we could perform
such cleanup when calling drop() too. This code can be further improved
by reimplementing wl-shm, which we need to do at some point in the
future.
This change introduces InputDevice::pointerFrame(). The main motivation
behind it is to allow batching multiple pointer events within a single
event frame.
BUG: 454428
1. In wl_output and kde_output_device_v2 protocols.
This should fix dpi calculation in
KScreen::Generator::bestScaleForOutput() when panel_orientation
is set to rotate a screen by 90 or 270 degrees.
2. When comparing with physical size of libinput device.
3. In calculations with mode sizes which are not rotated.
This change makes Output::physicalSize() return the raw
physical size, which is used in most of cases. It should
be rotated manually if needed.
If gbm_bo_get_fd_for_plane() or gbm_bo_get_fd() fails, ensure that the
gbm buffer allocator properly handles it and doesn't return a
GraphicsBuffer object.
The main motivation is to avoid scattering graphics buffer things around
kwin.
DmaBufParams struct has been moved to the OutputBackend, but with the
introduction of buffer allocators, we need to port screencasting code to
the new abstractions some time in the future.
A client can specify the following flags when creating a linux dmabuf
client buffer:
- y_invert
- interlaced
- bottom_first
Only the y_invert flag is supported by kwin. The interlaced and the
bottom_first flags are ignored. On the other hand, most clients don't
specify the dmabuf flags. For example, neither EGL nor Vulkan WSIs
use the y_invert flag.
The y_invert flag is undesired because it also blocks optimizations such
as direct scanout because DRM assumes that the origin is in the top left
corner.
Therefore, this change drops the support for linux dmabuf flags. From
the protocol perspective, this is fine. It can be viewed as buffer
import failing with the specified flags.
LinuxDmaBufV1ClientBuffer contains properties (formats, and flags) that
are not available in the base GraphicsBuffer type and there's no reason
to move it there.
In order to get rid of those properties (and eventually hide the
LinuxDmaBufV1ClientBuffer type from the public api), this change adds a
DmaBufAttributes getter in the GraphicsBuffer.
Currently, there exists the separation between the buffers provided by
the clients and the buffers created by the compositor.
In hindsight, this separation is not great because it leads to
specialized code paths in the output backend. For example, we have a
separate code path for direct scanout and presenting composited frame.
But you could view the latter case as "direct scanout of a compositor
buffer".
The main idea behind the buffer type is to provide a base buffer type
for client buffers and composited frame buffers (not drm fbs) that we
could pass around, import as textures, etc.
At the moment, the render backend provides its specific implementation
of LinuxDmaBufV1ClientBuffer. This has some of its limitations. For
example, due to the strong coupling, compositing restarts must be
handled carefully. It's hard to have a generic code path to import
dmabufs, which would be nice to have in order to unify graphics buffer
allocation across various backends; currently, it's all scattered.
To make the code simpler, this change drops the commented out YUV import
code path for now. Given that Mesa implicitly handles it, the need for
it is no longer so urgent.
