Summary:
A new method to tell the effects system whether the compositor scene
is able to drive animations. E.g. on software emulation (llvmpipe) it's
better to not do any animations at all.
This information can be used by effects to adjust their behavior, e.g.
PresentWindows could skip transitions or effects can use it in their
supported check to completely disable themselves.
As a first step all scripted effects are considered to be unsupported
if animations are not supported. They inherit AnimationEffect and are
all about driving animations.
The information whether animations are supported comes from the Scene.
It's implemented in the following way:
* XRender: animations are always supported
* QPainter: animations are never supported
* OpenGL: animations are supported, except for software emulation
In addition - for easier testing - there is a new env variable
KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2386
windowPixmap() is allowed to return a nullptr, thus we need to verify
that the returned pointer is not null. If it is null it's the same as
if there are no child WindowPixmaps.
Summary:
This change addresses the problem of the incorrectly rendered shadows
when opening a window (e.g. Kickoff) a second time. In case of e.g.
Kickoff not all elements are set, thus e.g. left might be 0, but right
has a value. So for calculating the height the maximum of the values
must be used.
Test Plan: Opened Kickoff and systray a few times
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1792
Summary:
The problem of the badly rendered shadows in case of opening kickoff
twice on Wayland is related to this. In that situation both the
width and height are 0. The rendering to the image fails and creating
the texture fails. This causes the flickering we see during rendering.
This change now discards such a shadow with an invalid size. This is
not fixing the actual problem of the shadow, but rather the symptom.
Nevertheless it's an important change as it makes it at least not
look fully broken.
Reviewers: #kwin, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D1790
Summary:
It's only needed by the standalone x11 variant. This allows us to
simplify the creation of the OpenGLBackend: it's created by the
platform plugin - we don't need custom complex logic.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1392
Summary:
If a window has an invalid size the decoration also has an invalid
size. This results in the texture used by the
SceneOpenGLDecorationRenderer to be invalid and being reset to null.
Of course we shouldn't try to use this texture to render to.
The change comes with a test case to simulate the situation. We cannot
simulate it with Wayland clients as the geometry can never be empty.
Thus we create an X11 client, resize it to an empty size and unmap it.
This is the first integration test case which creates an X11 Client!
It's also a test case which needs the OpenGL compositor. This will most
likely not work on build.kde.org yet - we need to see what to do about
it. Will need adjustments to get it at least skip on build.kde.org.
BUG: 361551
FIXED-IN: 5.6.3
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1383
Summary:
It can be null even after updateTextTexture() if there is not text
to generate the texture from:
if (m_effectFrame->text().isEmpty())
return;
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1347
This is more a hack than an actual implementation. It just renders
all sub-surfaces after the main window got rendered. But it does not:
* use window quads (e.g. splitting not supported)
* is not combined with rendering of the main surface
* does not support previous pixmap
Still it renders, which is the main goal at the moment.
the shadow can be deleted deferred from an update
there's a slight chance, to be eg. triggered by clients
blocking compositing, that the compositor is suspended in the same
cycle and the effects pointer (and scene and context) thus gone
CCBUG: 356938
FIXED-IN: 5.6
REVIEW: 126441
With this change a new ctor overload is added to ScreenPaintData
which allows passing a projection matrix through the effects. This
allows effects to put up custom shaders with a shared projection matrix
and without having to calculate it themselves.
The projection matrix is a read-only information for the effects. There
is no way to change or overwrite it.
For both simple and generic rendering the projection is actually the
same. So let's create it at the start of the frame rendering which
allows us to also pass it through the effects.
All backends already have an init method so far called from the ctor.
This change moves the call to init out of the OpenGL backends and makes
it the responsibility of the creating code to also call init on the
backend.
This change makes it easier to have virtual methods being called during
the initialization.
The last stage for window rendering is triggered by
Scene::finalDrawWindow. Adding a security check there if screen is locked
no non-lock screen window should be rendered.
Unfortunately this method is virtual so the check needs to be done in the
base and all implementing child methods (currently only OpenGL).
REVIEW: 126144
There are slight differences between GL_ARB_debug_output and GL_KHR_debug
affecting how it works on GLES. With GL_KHR_debug the context should be
created with a debug flag. With the ARB extension there is no such
requirement. Empirical data (Mali) shows that it doesn't work if the
context is not created with the flag, although the spec seems to allows
it.
So:
* if we have GL_ARB_debug_output we assume it works
* if we only have GL_KHR_debug we check whether the context is created
with debug support (which we don't do yet, but maybe should?)
* on GLES we can only query with version 3.2 (which we don't request yet)
* with anything older we just assume it's not enabled (which is correct
given that we don't enable the debug flag)
REVIEW: 126053
For the functions from GL_FOO_robustness we want to resolve it by
ourselves in order to add a custom implementation if it's not available.
Unfortunately once epoxy.h is included this breaks as epoxy defines the
names and so through the preprocessor epoxy always wins.
So we need different names: all functions from robustness get a "kwin"
prefix and the usage is changed everywhere in kwin source code.
REVIEW: 125883
-use qstringliteral only when necessary (i.e. not in concat or comparison)
-use qbytearray instead of qstring when dealing with latin1 input and output (glplatform)
-use qstringref to extract numbers from strings (glplatform)
-define qt_use_qstringbuilder to optimize all string concatenations
-anidata: use ctor init lists, add windowType member initialization
REVIEW: 125933
Compile failure on KDE CI:
error: ‘GL_GUILTY_CONTEXT_RESET’ was not declared in this scope
It's not defined in libepoxy 1.2, so let's define it to the values
it has in 1.3.
So far it was bound to whether we build for GLES. But this is
semantically wrong. It might be possible that even on desktop gl
epoxy is built without GLX support, thus we need to reflect this.
This change ensures that epoxy/glx.h is only included if available,
that relevant code is bound to it and that checks are in place to
enforce EGL if not build with glx support.
In addtion the glxbackend.cpp is now only included in the build set
if available.
For a virtual rendering backend a surfaceless context is needed. Such
a context may not call glDrawBuffer as that results in a GL error.
This change allows the OpenGLBackend to announce that it's context is
surfaceless.
It doesn't make much sense any more as we do no longer link EGL since the
switch to epoxy. And epoxy pulls it in at runtime if needed.
Even more on Wayland it's just plain stupid to have EGL disabled. So
removing the option just simplifies our code base without any
disadvantages.
REVIEW: 124695
When switching virtual terminals,
suspending to ram and resizing the
screen (GL viewport) at least the
nvidia driver moves VBO data between
the video RAM and the system heap -
and something about this isn't reliable:
An often perceived resulted are scattered
windows but it may also be the cause for
entirely black screens reported for same
occasions.
As a workaround, we hook into the GL debug
messages and filter them for the suspicious
message, then re-init VBOs
TODO:
figure whether that's our fault or nvidias
REVIEW: 123936
CCBUG: 344326
Patch applies to KWin 5.4
The complete rendering is now splitted per output including present which
means that we only need to make the context per output current once per
rendering.
Unfortunately our architecture does not properly support gathering the
damage for multiple outputs. In fact the damage information is lost after
the first output got rendered. Thus we currently only support buffer age
for the first output, on other outputs full repaints are caused.
For each DrmOutput a gbm_surface and EglSurface is created. When
rendering per screen the context is made current on each of the
surfaces.
Note: viewport handling needs to be improved by e.g. passing through
the scene to restore to correct viewport after dropping an FBO.
Furthermore it seems like buffer age is not working correctly in this
setup (not overly surprising).
Dynamic changes are not yet supported.
