The scratch PaintDevice is provided by the PaintRedirector's subclasses
allowing the ones wanting a QImage to provide the QImage directly and the
ones needing a QPixmap to provide a pixmap. This means the copy from
QPixmap to QImage is no longer needed in the OpenGL and XRender/raster
paint redirector.
REVIEW: 109138
Ownership of decoration textures is moved from SceneOpenGL::Window to
OpenGLPaintRedirector. The PaintRedirector is responsible for updating
the textures whenever they change. For this GLTexture is extended by an
update(QImage, QPoint) method which uses glTexSubImage2D to update only
the changed parts.
The big advantage compared to before is that if e.g. only a button is
animated only the button part is updated instead of the complete deco
part.
PaintRedirector is turned into an abstract class providing a factory
method which returns either an instance of
* OpenGLPaintRedirector
* NativeXRenderPaintRedirector
* RasterXRenderPaintRedirector
OpenGLPaintRedirector is basically doing exactly the same as the parent
class used to do before. Though the idea is to extend the functionality
to have the PaintRedirector write directly into OpenGL textures to limit
copying the complete decorations.
NativeXRenderPaintRedirector is similar to OpenGLPaintRedirector by
rendering into a QPixmap and providing the pictureHandle for the QPixmap
to SceneXRender.
RasterXRenderPaintRedirector is providing the functionality for the case
that the QPixmap/XPixmap relationship is not present. From the QPixmap
containing the pending decoration paint a QImage is created and then the
relevent parts are copied directly into the decoration pixmap.
REVIEW: 109074
The only task of the PaintRedirector is to redirect the painting of the
window decorations into Pixmaps. So it should actually do this by also
handling the four pixmaps for the decoration. This simplifies the code
as all the logic concerning redirecting the painting is now grouped
together.
Furthermore the PaintRedirector is now a child of the decoration widget,
which means it gets automatically destroyed whenever the decoration is
destroyed - the Client does not have to care about it.
Also the PaintRedirector gets only created if the Compositor is active as
it is not needed in the non-compositing case.
REVIEW: 106620
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
Martin Gräßlin
Philipp Knechtges
Martin Gräßlin
Fredrik Höglund
Jacopo De Simoi
Hugo Pereira Da Costa