A better alternative is to return the damage region in the beginFrame()
function. This way, the render backend can force full screen repaints or
indicate what parts of the buffer needs to be repainted (for buffer age)
The main motivation behind the split is to simplify client buffer code
and allow adding new features easier, for example referencing the shm
pool when a shm buffer is destroyed, or monitoring for readable linux
dmabuf file descriptors, etc.
Also, a referenced ClientBuffer cannot be destroyed, unlike the old
BufferInterface.
If window quads need to be generated after the wl_surface is destroyed,
the SurfaceItemWayland::mapToBuffer() function will return wrong values.
In order to fix that, we need to store the last surface-to-buffer matrix
in SurfaceItem.
DrmPipeline is now what contains all the thing related to drm calls,
instead of DrmOutput. This allows for some more flexibility and tidies
the code up a bit. Additionally instead of rolling back changes if
presentation fails, changes are directly tested with atomic test only
commits.
While always calling showCursor isn't a problem for when there's no
pointing device as the cursor image is empty in that case, it can
cause a temporarily stuck cursor image when it's supposed to be
hidden because of touch input
If a wl_eglstream buffer is attached to a surface, but then later a different
type of buffer, such as a dmabuf, is attached to the same surface, kwin will
mistakenly keep trying to acquire frames from the EGLStream associated with the
previous buffer. This can happen if an Xwayland window is made full-screen
causing it to switch to the flipping presentation path, for instance. The
result is that the window contents will no longer be updated.
Instead, the eglstream backend's loadTexture and updateTexture functions should
first pass the buffer to eglCreateStreamAttribNV. If it fails with
EGL_BAD_STREAM_KHR, that indicates it is indeed a wl_eglstream, and that we've
already associated a server-side EGLStream with it in attachStreamConsumer, so
we can proceed as usual. If it fails with EGL_BAD_ACCESS, though, that
indicates it is not a wl_eglstream and we should fall back to the parent class
which handles attaching other buffer types. If it doesn't fail at all, that
means the client tried to attach a new wl_eglstream to a surface without first
attaching the stream consumer. There's not really a great way to handle this,
so just re-use the previous EGLStream.
This is to ensure that both kwin and Qt use the same EGLDisplay. Note
that the native context handle can have no display, however it's very
unlikely to happen.
There are EGL implementations that will refuse to create a context if
the share context belongs to other EGLDisplay. Currently, that's the
case on some platforms.
If eglGetPlatformDisplayEXT() is called with the same parameters, it'll
return the same EGLDisplay. The main motivation behind this change is to
ensure that both kwin and Qt share the same EGLDisplay, QtXCB calls
eglGetPlatformDisplayEXT() without any additional args.
If EGL_PLATFORM_X11_SCREEN_EXT is not specified via attrs, the EGL
implementation will use the default screen, which is the same as
m_x11ScreenNumber.
Putting the OpenGL post processing rotation into its own class cleans
the EglGbmBackend code up a bit and adds post processing rotation for
the EglStreamBackend
Currently, if discard() is called, kwin will crash because
EglPixmapTexture does not override the discard method.
In principle, neither GlxPixmapTexture nor EglPixmapTexture should mess
around with internals of the GLTexture class. It is better to have a
wrapper texture with a bind method, which will re-bind the pixmap to the
opengl texture if necessary.
It seems like without a surface creation of the scene fails somehow. At
least until the exact problem is solved, update outputs for EglStream
gpus before creating the EglStreamBackend.
BUG: 438363
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.
Window quads need to be in some coordinate space. Since we want items to
be used not only for rendering windows, window-local coordinates do not
suffice.
This change makes scene items generate quads in the item-local coordinate
space.
The model matrix is used to map the quads to the global screen coordinate
system from the item coordinate space.
Since the quads are in the item local coordinate space, the mvp matrix
needs to be updated on every draw call. Given the render data, tracking
the last mvp matrix won't result in less glUniform calls. If this indeed
becomes a serious performance bottleneck, we can explore the possibility
of dumping mvp matrices in a UBO, which have been introduced in OpenGL
3.1.
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.
Drop-shadows with the software render backend impact performance quite
significantly. It also makes it easier to prepare render backends for the
item based design.
So far, we were creating a model view with the complete scene rendered
(even if we didn't render the windows themselves). This required us to
have a big glPerspective spanning the entire scene and we were just
cropping it as we rendered it into a smaller texture.
This changes our scenes so we have the correct matrix set up at all
times.
Specifically in the case of the Pinephone, this solves the following
issue where we were unable to connect external displays because it
exceeded GL_MAX_VIEWPORT_DIMS:
https://invent.kde.org/teams/plasma-mobile/issues/-/issues/11
The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
We used to get a weird line around the window decoration because the
clamping would hit the outside of the rendered decoration.
To make sure we fall inside take the displayPixelRatio into account.
Also on non-integer scales, make sure we are actually falling inside.
It was needed to work around visual glitches in the wobbly windows
effect. Since the wobbly windows effect renders the animated window into
an offscreen texture, we don't need this workaround anymore.
Furthermore, rather than using half-pixel correction, it is more
desirable to use an offscreen texture as it results in simpler design.
Performance-wise, it's not that bad that we need to start looking for
other ways to get rid of the seams between window contents and deco.
The backend can now optionally wait for the scene to be created before
it updates its outputs, which is necessary for better atomic tests in
the DRM backend.
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.
attachStreamConsumer and resetOutput are not called as part of the scene
render and as such the context might not be set.
All credit goes to Simon Spinner for his investigation.
BUG: 437573
With high DPI we can't use the image size as a logical size directly.
The other change is use of QPainter::drawImage(QRect target, QImage
image, QRect source)
This slightly confusing method uses logical pixels for the target, but
the source rect is in native pixels of the source.
BUG: 422342
If the egl backend gets deleted this leaves a dangling pointer. In
order to prevent crashes with QPainter or EglStreams also don't try
to create dmabuf textures without a EglGbmBackend.
So far we had a composition setup within kwinrc and kscreen. This
produces flickering sometime and makes the state a bit more flimsy.
This patch changes the kwin's behaviour to use the files produced by
kscreen which are anyways available down the line.
THis simplifies our behaviour down to just one format that we write to
and feed from. This also allows us to leverage it further by using this
format for default setups (which consist in the right file in
~/.local/share/kscreen).
One of the scene redesign goals is to make wayland surface items
re-usable. So we have the same rendering path for drag-and-drop icons,
software cursors, and window surfaces.
The biggest issue at the moment is that window pixmaps are tightly
coupled with scene windows.
This change de-couples window pixmaps from scene windows. In order to
achieve that, some architecture changes were made.
The WindowPixmap class was replaced with the SurfacePixmap class. A
surface pixmap is created by a surface item.
Under the hood, a SurfacePixmap will create a PlatformSurfaceTexture
object, which contains all the information necessary for the renderer.
The SceneOpenGLTexture class was removed. However, the GLX and the EGL
on X11 backends still mess with GLTexture's internals.
