AbstractEglBackend includes option.h, which includes main.h, which
includes QApplication. Since SceneOpenGLBackend doesn't link against
Qt::Widgets, kwin fails to build on Gentoo, but not on other distros
for some reason...
With the LEDs enum being defined in kwinglobals.h, wayland_server.h
won't need to include keyboard_input.h, which is good for compilation
times and wayland_server.h will drag less stuff, e.g. QtWidgets (input.h
includes QAction)
This change merges the two OpenGL backends into one making the current
default of GLCore the overall default. It becomes the first context to
try to create. If it fails, it will automatically fall back to the
(previous) OpenGL 2 backend.
Reasoning: the differentiation of OpenGL 2 and 3 is a very technical one
and hard to understand for users. It is not obvious which one is better
or should be used. This results in many user discussions like "Which
backend to use?"
Back when the OpenGL 3 backend was introduced the dedicated feature made
sense. It was a new code base using new driver features. Nowadays the
code base in KWin is robust and mature and so are the drivers. A driver
advertising support for OpenGL 3 will support OpenGL 3. We don't have to
plan for driver breakage in this area any more.
Also our code evolved through the context attribute builder which gives
us the possibility to more easily fall back in case we cannot create the
context. Thus the need to select the backend is not so important as it
used to be when the feature got introduced.
If a user still wants to force OpenGL2, it is still possible by setting
the appropriate environment variables like MESA_GL_VERSION_OVERRIDE.
This change brings the improvement that the backend selection is now
completely removed from the compositing KCM.
We use surfaceless contexts with internal windows. We also require
the EGL_KHR_surfaceless_context extension for making context current
without outputs.
Arguably, we could use pbuffers, but since mainstream drivers (Mesa and
NVIDIA) support surfaceless contexts, the extra complexity doesn't buy
us anything.
With per-screen rendering, every output may have different EGLConfig.
Having a single global EGLConfig doesn't work out well.
This change removes Platform::sceneEglConfig(). It's used primarily to
create the global share context. In hindsight, the global share context
can be created without EGLConfig as it's never made current.
EGL_NO_CONFIG_KHR is part of EGL_KHR_no_config_context extension, which
is supported by both Mesa and NVIDIA driver so it should be safe to make
it mandatory.
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.
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.
This allows creating a GLTexture object and attaching a dmabuf to it.
Currently, we can do that by using the foreign GLTexture constructor,
but it makes the deletion of the texture handle more error prone.
In the future, we can add a method that allocates the texture storage,
but there's no need for that yet.
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.
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.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
