ModelViewMatrix used to paint windows (which is aware about
multi-monitor configuration) was overriden by reflectionMatrix when
painting reflections, leading to wrong placement of reflections.
Now we just multiply old matrix and reflection matrix.
BUG: 378688
Differential Revision: https://phabricator.kde.org/D10465
Summary: Fixes the build with D8705
Test Plan: Just adds includes, I wonder if it should go into Plasma/5.8 and /5.11 too
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8706
Summary:
By changing all kcfg to have arg="true" we can pass in the same
KSharedConfigPtr into all effects. This allows to have fake config in
the tests and in the planned effect demo mode.
Also it means that we don't have to hardcode the name kwinrc into the
files. In the configs - where we cannot access the effectshandler - we
use the define KWIN_CONFIG which gets generated based on the compile
time arguments.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3571
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
One resource is used for shader version 1.10 and one for version 1.40.
The ideas behind this change is to remove the locating of the shader
sources and also to fix that user provided shaders could be loaded
instead of the original ones (possible attack vector on Wayland).
To simplify the ShaderManager provides a new method call to load the
shader from the resource. This means the effects don't need to
duplicate the check for the shader version any more and also don't
need to duplicate the file reading functionality.
REVIEW: 126905
Most of those effects didn't need special screen locking handling on
X11 as they prevented screen locking. On Wayland though, we don't
want the lock screen shown on a cube.
REVIEW: 126122
Moves calculation of projection and modelview matrix
(aligned to new scene_opengl code) to effect start,
caches the matrices in private members and sets them
on WindowPaintData
BUG: 343509
REVIEW: 122355
FIXED-IN: 5.3
This removes all the hacks to add kwin4_effect_ to the name of the Effect
and adjusts the desktop files of the effect configuration's parent
component.
Note: the scripted effects still start with kwin4_effect_ prefix.
REVIEW: 117367
All KCMs and KWin core use the BuiltInEffects namespace to find and
interact with the effects. There is no information left in the desktop
file which are of usage. Thus they can be removed.
This method replaces the X-KDE-ORDERING property in the Effect's desktop
files. This change is a preparation step for integrating the new Effect
Loader which doesn't read the ordering information. Thus it needs to be
provided by the Effect itself so that the EffectsHandler can properly
insert it into the chain.
Also for the built-in Effects on the long run it doesn't make much sense
to install the desktop files. And binary plugin effects will migrate to
json metadata which also doesn't have the KService::Ptr. Thus overall it
simplifies to read this information directly from the Effect.
Most is just switched to the ::read(). That should be enough for all the
Effects which have a KSharedConfig::Ptr underneath. If not we just need
to find a good place to put the reload.
Instead of using EffectsHandler::sendReloadMessage we generate the dbus
interface in each plugin and call the reconfigure slot directly. That way
it's more type safe and we don't need to link kwineffects from the
configs.
REVIEW: 116875
There are no advantages for the effects KCM to have all the effect
config modules in one plugin.
By having a plugin per effect we can use the KPluginTrader to easily
find the configuration plugin for a given effect and load it.
To make this possible the following changes are done:
* config_builtins.cpp is deleted
* add_subdirectory is used for all effects which have a config module
* toplevel CMakeLists.txt contains the sources again for the effects
which have a config module, but effects which don't have a config
module are still included and thus the macro is still used
* plugin created for the config module, name pattern is:
kwin_effectname_config
* plugin installed to ${PLUGIN_INSTALL_DIR}/kwin/effects/configs
* desktop file adjusted to new plugin name and keyword removed
* desktop file converted to json as meta data and no longer installed
* Uses K_PLUGIN_FACTORY_WITH_JSON
* Macros for config are dropped from kwineffects.h
REVIEW: 116854
X-KWin-Internal should be used for effects which are either internal
to KWin and are configured at a different location in KWin. Examples
are:
* CoverSwitch - configured in WindowSwitcher KCM, but not FlipSwitch
as that one has a non WindowSwitcher mode
* window geometry - configured in moving
And it should also be used for helper effects to the overall
kde-workspace module. Examples are:
* Dashboard - required by Plasma
* KScreen - required for KScreen
* Screenshot - required by KSnapshot
Why a new category and not the already existing NoShow property?
The idea is to just filter on the effects in the list. Thus it should
be possible to show them. But NoShow is clearly intended to not be
shown at all.
REVIEW: 116754
KWin already has a de facto OpenGL 2 dependency through QML. Combined
with the fact that the OpenGL 1 backend is basically unmaintained and
also unused, it's better to remove it for the new major release.
This change includes:
* Removal of cmake option KWIN_BUILD_OPENGL_1_COMPOSITING
* Removal of KWIN_HAVE_OPENGL_1 compile option and all code
ifdef'ed with it (partially removal of if-else constructs)
* Removal of CompositingType::OpenGL1Compositing (flags are kept
as a core flag should get introduced)
* Driver recommendation for OpenGL1Compositing changed to XRender
(should be evaluated whether the drivers can provide GL2)
* Removal of configuration option "GLLegacy"
* Removal of fooMatrix function in kwinglutils
* Removal of ARBBlurShader
* Removal of legacy code path in GLVertexBuffer
* Removal of GLShaderManager::disable
* if-blocks with ShaderManager::instance()->isValid() removed
REVIEW: 116042
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
Vlad Zagorodniy