Reflection in a vertical multiscreen setup are kind of broken without
PaintClipper. But we have to ask ourselfe whether CoverSwitch in a
vertical multi screen setup makes sense and whether it's useful to
have reflections in such a setup.
Horizontal multiscreen setup works fine (also with reflections).
We have to set the bit depth of the XPixmap to 32 in order to get
an alpha channel and we have to render the grabbed image using
composition mode Source in order to just copy all pixels to the
destination pixmap.
BUG: 276719
FIXED-IN: 4.7.0
Since the funtionality of TopMenu did no longer work in KDE4 this feature was
removed from Workspace. Every reference to it was removed as well as commentaries
and documentation.
REVIEW: 101485
The uniforms textureWidth and textureHeight were only needed for
normal windows. For everything else it was just 1.0/1.0, that is
normalized.
The makeArrays method is changed to produce normalized texcoords
obsoleting the need for these uniforms. So two uniforms less, one
calculation in vertex shaders less and many many lines of code
removed.
At the same time makeArrays is also adjusted to take care of
yInverted of the texture, which is needed as we no longer can use
the enableUnnormalizedTexCoords which did the yInverted transformation.
REVIEW: 101646
Actually it's more a hack and should be addressed in the next
release cycle by allowing effects to modify the scene's blend
equation.
BUG: 274424
FIXED-IN: 4.7.0
For what reason ever motion manager thinks that windows are not
moving during the start animation (but are during the stop animation).
So we also have to look on the timeline to decide whether we should
disable lanczos filter on the windows.
Now wonder the animation was stuttering.
BUG: 274292
FIXED-IN: 4.7.0
Due to changes in the blur effect, the EffectFrame was flickering
with GLES. This can be worked around by doing full repaints whenever
a window is damagded while boxswitch is active with GLES. The problem
only occurs with the GLES backend due to the way how the buffers are
swapped.
BUG: 272688
With raster a QPixmap is no longer a XPixmap which fails all code
which assumes that an QPixmap is an XPixmap. Depending on were in
the codebase we either convert such pixmaps to images (OpenGL) or
create a XPixmap and use QPixmap::fromX11Pixmap to get a "real"
pixmap.
It is possible that there are more code pathes were we would need
a XPixmap. Currently tested is basic functionality of no-compositing,
XRender compositing, OpenGl/GLX and OpenGL ES/EGL compositing.
For OpenGL compositing raster might result in performance improvements,
for XRender it is possible that there are regressions when using raster.
By default KWin uses whatever is the default of the system, so we just
no longer enforce native.
Of course it is a bad idea to use graphicssystem OpenGL. As that
is broken anyways in Qt, we do not check for it.
Many thanks to Philipp Knechtges for bringing up the issue, convincing
me that we need it and providing most of the patch.
REVIEW: 101132
CCMAIL: Philipp.Knechtges@rwth-aachen.de
