avoiding the blocking swapinterval detection causes
issues in the timing strategy and prevents protection
against CPU overload on the nvidia blob
BUG: 329821
FIXED-IN: 4.11.6
REVIEW: 115306
By setting the X property _KDE_NET_WM_SKIP_CLOSE_ANIMATION to 1 a window
can request to be excluded from any close animation. This property is
read in Toplevel, so that it is available to both Client and Unmanaged.
If the window has this property set the Scene suppresses the paintWindow
loop of the Deleted. Thus no effect needs to be adjusted. But an effect
using drawWindow directly would still be able to render the Deleted as
there is no suppression.
Furthermore the property is passed to the EffectWindow so that an
Effect can make use of this functionality and not start the animation
in the first place.
REVIEW: 115288
CCBUG: 279615
Backported from 9497b4ddb681ac50dbe9c015e05a3f12fd496da8
After losing current from the EGL or GLX
context, calls to the GL or GLES functions
have undefined behavior. Perform all
cleanup that may touch OpenGL and check for
GL errors before losing current from the
context.
REVIEW: 115311
By setting the X property _KDE_NET_WM_SKIP_CLOSE_ANIMATION to 1 a window
can request to be excluded from any close animation. This property is
read in Toplevel, so that it is available to both Client and Unmanaged.
If the window has this property set the Scene suppresses the paintWindow
loop of the Deleted. Thus no effect needs to be adjusted. But an effect
using drawWindow directly would still be able to render the Deleted as
there is no suppression.
Furthermore the property is passed to the EffectWindow so that an
Effect can make use of this functionality and not start the animation
in the first place.
REVIEW: 115288
Loading all effects during startup can take some time[1] and during
that time the screen is frozen as the loading blocks the compositor.
This change doesn't load effects directly but puts them into a queue.
The loading is controlled by invoking the dequeue through a queued
connection. Thus we get a firing compositing timer in between and can
ensure that a frame is rendered when needed and also react to X events
during the loading.
[1] On my high-end system the set of effects I use take about 200 msec
to load.
REVIEW: 115297
KWin starts to support the Notification window type and has an own
layer for all notification windows. They are kept above the above
layer but do not go over active fullscreen windows.
REVIEW: 115298
As all effects have always been compiled into the same .so file it's
questionable whether resolving the effects through a library is useful
at all. By linking against the built-in effects we gain the following
advantages:
* don't have to load/unload the KLibrary
* don't have to resolve the create, supported and enabled functions
* no version check required
* no dependency resolving (effects don't use it)
* remove the KWIN_EFFECT macros from the effects
All the effects are now registered in an effects_builtins file which
maps the name to a factory method and supported or enabled by default
methods.
During loading the effects we first check whether there is a built-in
effect by the given name and make a shortcut to create it through that.
If that's not possible the normal plugin loading is used.
Completely unscientific testing [1] showed an improvement of almost 10
msec during loading all the effects I use.
[1] QElapsedTimer around the loading code, start kwin five times, take
average.
REVIEW: 115073
We need to use the varying_in/out variables, the code was a little
bit too modern.
At the same time remove the identity matrix and replace it by mat4(1.0).
Note: the shader should probably go into glsl files as they are not
really generated.
* this effect is way cheaper than blur, don't cache it
* use its own atom
* also pass the matrix in the x property
* remove remnants of the cache
* do just a single pass
* get rid of config ui remnants
* a copy of the blur shader to become a copy of the background contrast effect
* contrastshader actually doing the light modification
* don't expand/shrink the area
It's possible that the Client does not have an effect window when
the desktop presence changes. This results in a crash.
Unit test which triggered the crash on
https://git.reviewboard.kde.org/r/115190/
REVIEW: 115214
It's 2014 and we don't have to wait half a minute for an application
to start. In fact we mostly get false positives due to applications
not handling correctly startup notifications for already running
instances (e.g. click on link in email).
So let's reduce to a default which doesn't look like a broken setup.
REVIEW: 115046
