Creating an EffectFrame requires I/O which takes on my system
during testing between 10 and 40 msec. Also it needs a little
bit of memory.
This changes moves out the creation of EffectFrames at Effect
load till the Effect actually needs the EffectFrame. E.g. if a
user does not filter in PresentWindows there is no need to ever
create it.
BoxSwitch effect is ignored as it should be dropped for 4.9.
REVIEW: 104815
Cube effect loads 0 to 2 textures which has been
performed during configuration. This change delays
loading the textures till cube is activated for the
first time and the loading from file is moved into
a thread.
This means that for a very short time the texture
is not yet visible, but this is not a problem as
the cube animates from fully opaque starting state.
So during the loading the texture would not be
visible anyway.
REVIEW: 104807
Client::manage calls setupCompositing on the not
yet fully managed client before it wants to create
the window decoration. This means the decoration is
created twice and maybe even if not needed (noBorder
not yet set).
If the Client is not yet managed setupCompositing
will not update the decoration - it will be handled
by manage later on.
Furthermore if compositing is not active, setup
compositing does not have to perform any action.
REVIEW: 104758
By moving the query for effects into an own thread the
startup does not have to wait till all effects are loaded.
The thread moves the loading of the effects after the
Window Manager and Compositor has been fully initialized.
This is possible as EffectsHandler is fully functional even
without any effects.
The compositor ensures that at least one frame is rendered
before the started thread returns which makes the complete
startup more responsive.
REVIEW: 104583
The I/O intensive reading of the complete KWin Script
file into a QByteArray is moved into a thread.
Evaluating and setting up the script engine is still
performed in the main thread.
REVIEW: 104782
Searching for the scripts to load is performed in an own
thread including unloading of already loaded scripts which
no longer should be loaded.
To ensure that two threads are not trying to load/unload
at the same time a mutex is added to protect the list of
loaded scripts.
REVIEW: 104768
Instead of getting the information from CompositingPrefs
the running KWin instance is queried through D-Bus.
In general the running KWin should have more information
about whether Compositing will work or not.
This means the kcm no longer has to link OpenGL.
REVIEW: 104753
Detecting CompositingPrefs invokes an external program. Waiting
for this can be moved in a second thread.
Due to the introduction of the thread the initialization order
of KWin is changed: the WindowManager is initialized before the
Compositor. Interestingly this makes KWin felt more responsive
as the screen is not frozen for several seconds.
REVIEW: 104579
Whether creating the OpenGL context succeeds or not
had no influence in any decisions on the used settings
for OpenGL based compositing.
The only valid information CompositingPrefs still detects
is whether direct rendering should be used which is
performed out of process and does not require a context.
So overall the context creation is not needed and can
be removed.
REVIEW: 104778
This means the GLPlatform is filled with values from the
context actually used for Compositing and if XRender
compositing is used no OpenGL information is logged.
There is no need to have it driver specific any more.
All drivers seem to support it (only Intel had been
opt-ed out without any apparent reason shown in commit log).
This was the last driver specific setting which means that
the method applyDriverSpecificSettings() got dropped from
CompositingPrefs.
Strict binding follows the driver (GLPlattform) unless
the user has a config value specified in the kwinrc.
For this a new property is added to Options to indicate
whether strict binding is user defined or follows the
driver. In case of driver the strict binding option is
set when OpenGL compositor starts up.
Toplevel::setupCompositing returns a boolean value and returns
false in the cases where it has not setup compositing.
This is used by the specialization on Client to not perform the
Client specific setup if Toplevel has not setup.
REVIEW: 104767
Workspace emits a signal when the initialization finished and
interested parties can connect to this signal to perform post
init actions. That is everything that does not have to be
performed to have a completely working Window Manager.
As an example loading the scripts is moved into this post init
phase.
REVIEW: 104580
CompositingPrefs have only be used to get the default
value when reading whether the Compositing Enabled
config option.
But CompositingPrefs always returns true which makes
it useless to create an OpenGL context for this.
REVIEW: 104752
The change to have stacking order containing
Toplevel inestead of Clients (431aad6d6994695e72697fcc3299ec2cb6f0684e)
introduced possible crashers as recognized in:
http://git.reviewboard.kde.org/r/104519/#review12714
This change fixes these issues by adding missing
null pointer checks after casting to Client.
BUG: 298669
FIXED-IN: 4.9.0
REVIEW: 104714
This enables the script wrapper objects to automatically create new
dynamic properties for Client objects so that scripts can register custom
properties.
REVIEW: 104697
Options loading is split into three parts:
* reparse configuration
* loading of non-compositing related options
* loading of composited related options not needing CompositingPrefs
At startup the reparsing of configuration is done through a Thread
to gain a little bit of less waiting.
Before something else accesses the KConfig for the first time we
wait for the thread to finish and perform the other two loading
operations of Options.
The settings depending on CompositingPrefs will only be invoked
if a compositor is going to be needed.
REVIEW: 104562
