largely reverts b164e9912c9b5f9c9ae619bbd79355d317174115
which prevented the crash but due to early screen updating
causes issues with scene/overlay update on at least intel chips
BUG: 322970
FIXED-IN: 4.11
CCBUG: 322156
REVIEW: https://git.reviewboard.kde.org/r/111811/
This happens because some distros ship broken installations
of KWin and KWinActive, but could also appear to QML hacking users
BUG: 322830
FIXED-IN: 4.11
REVIEW: 111732
Not correct crossfading
Purpose of the hotfix is to manipulate opacities of the "semi-crossfaded™"
pixmaps so that on a quick animation and sloppy check it looks somehow
believable (instead of bumping the window to full opacity)
REVIEW: 111888
insufficient since there can be windows/content on top of the
moved window and the labels are painted on top of the scene
BUG: 318390
FIXED-IN: 4.11
REVIEW: 111861
when the option changes, the compositor needs to update
the state as it will later not act (in the disabled case)
and should to reflect the option change.
REVIEW: 111867
BUG: 322633
FIXED-IN: 4.11
1. it apparently is ineffective
2. if it was effective, it's current behavior would be not exactly helpful
(sets __GL_YIELD to NOTHING, causing busy waits on doublebuffer swapping)
3. it does for sure pollute the doublebuffer/usleep detection (setenv is set to override),
ie. the overehad detection code gets a different opinion on __GL_YIELD than libGL
REVIEW: 111858
CCBUG: 322060
the present check can break quick everything depending
on screen snapping settings.
It so far. only worked for quick maximization due to horizontal
"judder" and failed whenever that judder was not possible
(due to screen snapping on left and/or right edge)
BUG: 322852
FIXED-IN: 4.11
REVIEW: 111740
enforce to "e" (cheap) when driver is still unknown after
detection must be assumed to have run, so a sane value is available
when the context is up
BUG: 322355
FIXED-IN: 4.11
REVIEW: 111548
at the same time using MaximizeArea instead MoveArea
ratio:
movearea allows to pack windows under panels and while
one can expect users of packing to know alt+lmb, we usually
do not allow to loose the titlebar
Moreover this relies on packing against dock windows what
fails with "virtual" struts as input shaping panels
(eg. cairo-dock?) might use (ie. we we would also have packed
against plasma panel shadows - back then ;-)
BUG: 180084
REVIEW: 111603
FIXED-IN: 4.11
On GLES, check for OES_texture_3D extension for color correction
Remove a block of ugly hack code that was supposedly needed to build
with OpenGL ES.
Convert the lookup texture data to uint8 on OpenGL ES before sending it
via glTexImage3D, because uint16 is not supported.
Check if the shaders have been reinitialized successfuly when trying to
activate color correction, prevent black screens when there are issues
with the shaders.
BUG: 315419
REVIEW: 111225
(cherry picked from commit 68c68ee3c2b54f968c4d8275f1e8a2e0ccc90dd7)
capping shadows is seen as bug (and is ugly and
because of the non lanczos transition causes visual
flicker) so if the window+shadows extends the buffer,
lanczos is simply not possible.
BUG: 314838
FIXED-IN: 4.11
REVIEW: 111425
the only thing it does on these systems is cause users
trouble because usually when there's a client where
unredirection makes sense, that uses OpenGL - and then
things break in the driver.
CCBUG: 252817
REVIEW: 111476
The logics relied on a static timout to arm the timer:
when last successfull activation had been longer ago than 250ms.
We now cap the configured reactivation timeout at min 250m
guessing that this was somehow supposed as well by this.
BUG: 322057
FIXED-IN: 4.11
REVIEW: 111549
when visualPixels is not 0, this means the titlebar does
not touch an upper/lower border, thus moving that direction
is ok and protection should be sought horizontally
BUG: 322507
FIXED-IN: 4.11
REVIEW: 111573
Thomas Lübking