The Compositor class actually behaves like a Singleton so it should be
one. Therefore four static methods are added:
* self() to access the Singleton
* createCompositor() to be used by Workspace to create the instance
* isCreated() to have a simple check whether the Singleton is already
created
* compositing() as a shortcut to test whether the compositor has been
created and is active
The isCreated() check is actually required as especially Clients might
be created and trying to access the Compositor before it is setup.
The refactoring of Compositor starting with b1739c3 caused some
regressions due to variables in Workspace and Compositor not
being initialized. Furthermore there was a boolean logic error
in PaintRedirector causing the decorations not to paint.
BUG: 305875
The Scene has always been created and destroyed inside what is
now the split out compositor. Which means it is actually owned
by the Compositor. The static pointer has never been needed
inside KWin core. Access to the Scene is not required for the
Window Manager. The only real usage is in the EffectsHandlerImpl
and in utils.h to provide a convenient way to figure out whether
compositing is currently active (scene != NULL).
The EffectsHandlerImpl gets also created by the Compositor after
the Scene is created and gets deleted just before the Scene gets
deleted. This allows to inject the Scene into the EffectsHandlerImpl
to resolve the static access in this class.
The convenient way to access the compositing() in utils.h had
to go. To provide the same feature the Compositor provides a
hasScene() access which has the same behavior as the old method.
In order to keep the code changes small in Workspace and Toplevel
a new method compositing() is defined which properly resolves
the state. A disadvantage is that this can no longer be inlined
and consists of several method calls and pointer checks.
Instead of scheduling and gathering the Workspace::addRepaint calls at the end of the main loop
we directly emit the signal which ends up in a call to addRepaint. The compositeTimer assures
that the higher number of scheduled repaints are executed in the same rendering pass.
Without Compositing we do not really need the PaintRedirector,
it only adds overhead. This reverts the behavior to how it was before
the PaintRedirector was introduced by just not redirecting the paint
in the event filter when compositing is not active. This should have
the lowest impact on the existing source base.
The change breaks at least oxygen window decoration when compositing
is not active as the decoration is no longer double buffered. But
as written this is exactly the behavior as used before 4.3. Given
the push today there should be enough time for all affected decos
to adjust to the change.
REVIEW: 101413
in case we need it again.
This should improve performance with drivers where creating pixmaps is
expensive.
svn path=/trunk/KDE/kdebase/workspace/; revision=1104069
