I first thought this only affects maximized windows, but then experienced this without. * Maximize a window * trigger "present windows" -> the maximized window does not have a shadow. Hover it and the shadow appears for a moment, disappears again. If that happens present windows can flicker. Flickering looks like the window gets painted once without shadows, resized to the area the window + shadows should occupy. I realized this first when I set shadows quite large (active 50px, inactive 30). I THINK this may be a calculation error, as it looks like when actual window size + top shadow + bottom shadow > screen height this problem appears. Reproduced this with 4.10.0 and 4.9.5. Reproducible: Always
can you add a screenshot/screencast of the flicker you see? There should not be a shadow so I just fail to understand the problem ;-)
Created attachment 77098 [details] screenshot The small dolphin window has shadows, the big browser window does not. I tried to create a screencast, but quality is so bad (flickering where there was none, out of vsync) and the file would get really big, I think it is useless.
Please try with "notbespin" - i had some experimental change to disable shadows on maximized windows (but skipped it and hopefully didn't commit) Does it also happen with xrender (this time again with bespin ;-)
Set all to oxygen, logged in + out - same issue. I have a intel HD3000 (if that matters) The other PC (nvidia 220 GT) has a complete QtCurve-setup, same issue. When switching from OpenGL to XRender all decorations keep their shadows in present windows.
Lanczos filter. I think this is a dupe then (at least there was a similar bug with insufficient buffersize)
I guess I see the same error. As described, maximized windows don't carry a shadow, but smaler windows do. But their shadow is not as usual, but completely white (see screenshot)
Created attachment 79573 [details] Present Windows effect while failing on shadows.
is this the same (lanczos) bug of Present window effect being clunky when Scale method is set to Accurate with intel snb hardware?
(In reply to comment #8) > is this the same (lanczos) bug of Present window effect being clunky when > Scale method is set to Accurate with intel snb hardware? No. And iirc the snb issue was resolved in the driver (was about shader compilation overhead)
> (In reply to comment #8) > > is this the same (lanczos) bug of Present window effect being clunky when > > Scale method is set to Accurate with intel snb hardware? > > No. And iirc the snb issue was resolved in the driver (was about shader > compilation overhead) mh.. anyway that bug is still present here in 4.11 on very latest archlinux pkgs..
(In reply to comment #10) > mh.. anyway that bug is still present here in 4.11 on very latest archlinux > pkgs.. Please file a bug and attach "qdbus org.kde.kwin /KWin supportInformation" *there*
Git commit 4d77129313ba0d38b8d5689108849615cfd2ef98 by Thomas Lübking. Committed on 07/07/2013 at 11:57. Pushed by luebking into branch 'KDE/4.11'. rather omit lanczos than capping windows 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. FIXED-IN: 4.11 REVIEW: 111425 M +8 -22 kwin/lanczosfilter.cpp http://commits.kde.org/kde-workspace/4d77129313ba0d38b8d5689108849615cfd2ef98