Bug 314838 - Present windows: shadows flicker with large windows
Summary: Present windows: shadows flicker with large windows
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: scene-opengl (show other bugs)
Version: 4.10.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/111...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-10 18:18 UTC by Franz Trischberger
Modified: 2013-07-19 20:39 UTC (History)
2 users (show)

See Also:
Latest Commit: http://commits.kde.org/kde-workspace/4d77129313ba0d38b8d5689108849615cfd2ef98
Version Fixed In: 4.11
thomas.luebking: ReviewRequest+

Attachments
screenshot (134.85 KB, image/jpeg)
2013-02-10 18:46 UTC, Franz Trischberger 		Details
Present Windows effect while failing on shadows. (339.24 KB, image/png)
2013-04-30 14:38 UTC, Wolfgang Mader 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Franz Trischberger 2013-02-10 18:18:58 UTC 
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
Comment 1 Martin Flöser 2013-02-10 18:27:36 UTC 
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 ;-)
Comment 2 Franz Trischberger 2013-02-10 18:46:17 UTC 
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.
Comment 3 Thomas Lübking 2013-02-10 18:49:18 UTC 
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 ;-)
Comment 4 Franz Trischberger 2013-02-10 18:57:07 UTC 
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.
Comment 5 Thomas Lübking 2013-02-10 19:20:43 UTC 
Lanczos filter.
I think this is a dupe then (at least there was a similar bug with insufficient buffersize)
Comment 6 Wolfgang Mader 2013-04-30 14:37:21 UTC 
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)
Comment 7 Wolfgang Mader 2013-04-30 14:38:32 UTC 
Created attachment 79573 [details]
Present Windows effect while failing on shadows.
Comment 8 rockonthemoonfm 2013-07-05 13:58:12 UTC 
is this the same (lanczos) bug of Present window effect being clunky when Scale method is set to Accurate with intel snb hardware?
Comment 9 Thomas Lübking 2013-07-07 09:02:17 UTC 
(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)
Comment 10 rockonthemoonfm 2013-07-07 11:59:46 UTC 
> (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..
Comment 11 Thomas Lübking 2013-07-07 12:01:47 UTC 
(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*
Comment 12 Thomas Lübking 2013-07-19 20:39:53 UTC 
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