Rational behind this change is that displayWidth and displayHeight are
X specific API calls in kwinglobals. For the future it's easier to only
rely on functionality which goes through the EffectsHandler API which
allows easier adjustments in KWin core.
displayWidth() and displayHeight() are only used to get the size or the
complete rect of all screens. This is also provided by:
effects->virtualScreenGeometry() or
effects->virtualScreenSize()
REVIEW: 116021
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
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
In effects it's obvious that compositing is enabled, so specifying the
translucent element is no problem.
In tabbox a context property "compositing" is injected which decides
whether "translucent" or "opaque" elements should be used. Here the
translucent elements are only used if the Blur effect is available - for
this a new Effect::Feature Blur is introduced and in addition it is
tested whether the theme provides the translucent element.
Also the masking is adjusted to ensure that only the shadow is not
blurred.
Reason for this change is that Plasma theme seems not always to pick up
whether compositing is used when used from inside KWin. It does not cover
the Desktop Change OSD which uses PlasmaCore.Dialog and there we cannot
(yet) inject that we use compositing.
Overall I'm quite unhappy with this patch and I do hope we can fix it in
the proper place in the lifetime of 4.10 and revert this patch.
CCBUG: 311995
REVIEW: 108438
Instead of each effect, which needs to announce support, having custom
code to create a property and set it on the root window, there is now a
common API in EffectsHandler to take care of this.
The methods takes care of creating the atom if it has not already done
and set the property on the root window. Furthermore it allows multiple
effects to announce the same property without getting in conflict with
each other.
As a further convenience the property is automatically removed when the
effect is unloaded, so less things an effect author has to care about.
REVIEW: 107815
A decoration can provide the AbilityAnnounceAlphaChannel in addition to
AbilityUsesAlphaChannel. If this ability is provided the decoration can
enable/disable the use of the alpha channel through setAlphaEnabled().
The base idea behind this mechanism is to be able to tell the compositor
that currently alpha is not needed. An example is the maximized state in
which the decoration is fully opaque so that there is no need to use the
translucency code path which would render all windows behind the deco.
In addition also the blur effect honors this setting so that behind a
known opaque decoration no blurring is performed.
Oxygen is adjusted to disable translucency in maximized state and Aurorae
is adjusted to allow themes to enable/disable translucency. For Plastik
translucency and with that also blurring is disabled.
REVIEW: 106810
The logic has already ensured that the ARBBlurShader can only be used
when using the OpenGL1 compositor, the OpenGL 2 compositor needs to use
the GLSLBlurShader.
This change moves the complete ARBBlurShader into a KWIN_HAVE_OPENGL_1
ifdef section.
As a side-effect the ::create method can now return a NULL pointer which
makes more sense then returning an ARBBlurShader in case that the
GLSLShader is not supported.
REVIEW: 106738
If the build option is enabled KWIN_HAVE_OPENGL_1 is passed as a compile
flag when build against OpenGL.
This compile flag is meant to replace the KWIN_HAVE_OPENGLES. So far code
has been ifdefed for special behavior of OpenGL ES 2.0 and to remove
fixed functionality calls which are not available in OpenGL ES 2.0.
With this build flag the fixed functionality calls which are only used in
the OpenGL1 Compositor can be removed and keeping the KWIN_HAVE_OPENGLES
for the real differences between OpenGL 2.x and OpenGL ES 2.0.
E.g. a call like glColor4f should be in an
glColor4f(1.0, 1.0, 1.0, 1.0);
while a call like glPolygonMode should be in an
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
Building for OpenGL ES 2.0 of course implies that KWIN_HAVE_OPENGL_1 is
not defined.
Given that the Catalyst driver is now supporting direct rendering and by
that can use the OpenGL 2 code path we do no longer need to force
disable the Blur effect and Lanczos filters which used to crash in the
ARB shader path.
The ARB shader path - which can only be used in OpenGL 1 - is kept
disabled for Catalyst.
CCBUG: 270818
CCBUG: 286795
REVIEW: 106798
The main usage of ShaderManager::isValid was to have OpenGL2 specific
code pathes. Now we have an actual OpenGL2Compositing type and we know
that the ShaderManager is valid if we have this compositing type and we
know that it is not valid on OpenGL1Compositing. This gives us a much
better check and allows us to use the isValid method just for where we
want to check whether the shaders compiled successfully.
In addition some effects require OpenGL2, so we do not need to check
again that the ShaderManager is valid. Such usages are removed.
The supportInformation is extended to also read the properties
on all effects. In addition each effect can be queried just for
itself through D-Bus, e.g.:
qdbus org.kde.kwin /KWin supportInformationForEffect kwin4_effect_blur
All effects are extended to provide their configured and read
settings through properties. In some cases also important
runtime information is exposed.
REVIEW: 105977
BUG: 305338
FIXED-IN: 4.9.1
The public member variables for opacity, saturation and brightness
are removed in favor for getter and setters. The variables are
moved into a private class. Those are now qreal instead of double.
To make usage inside the effects easier a multiply method is added
which multiplies the current value with passed in factor and returns
the new value in a functional programming style.
This commit is the top-most of a patch series to refactor
ScreenPaintData and WindowPaintData. Other related commits are:
* 0811772
* ebdc7ec
* 2c8dd8d
* 7699726
* 68e0201
* 611cb09
REVIEW: 105141
BUG: 303314
FIXED-IN: 4.10
No effect has ever made use of contents opacity. Which means it
is not needed. Removing means faster effects as we used to
multiply the value (always 1.0) with the opacity in each frame
for each window.
Effects can specify their minimum requirements in their
desktop file:
* OpenGL
* OpenGL 2 (GLSL required)
* Shaders (either ARB or OpenGL 2)
The configuration module uses this information in combination
with which backend KWin is currently using. So if e.g. OpenGL
is used and an effect requires OpenGL 2 a detailed error
message can be showed that OpenGL 2 is required.
BUG: 209213
FIXED-IN: 4.9.0
REVIEW: 104847
This makes kwin in OpenGL2 mode more coherent with kwin_gles.
Despite some fullscreen effects they should now make the same
(pure) OpenGL calls.
REVIEW: 103804
This reduces the repaints in cases where several blur regions are
stacked on top of each other (e.g. oxygen-transparent) and the topmost
layer needs to be updated (e.g. a blurry window is moved).
The old blur version wrongly marked a cache region as valid with the
reason that this region would never become visible. It didnt matter
because the only case that this region could become visible was a
movement of the window on top, which back then would have forced a
workspace repaint of that region and as such would have invalidated
the cache anyway. With the introduction of addLayerRepaint the
last point is no longer true and we have to track the valid cache
regions more carefully.
