Bug 293236 - When "dim inactive" is used, and "apply effect to groups" is disabled, blocky shadows appear everywhere
Summary: When "dim inactive" is used, and "apply effect to groups" is disabled, blocky...
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: 4.11
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-03 20:23 UTC by Christopher Neufeld
Modified: 2013-05-21 06:55 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screen shot of the bug. Mouse pointer (not visible) is in the centre bottom konsole (545.82 KB, image/png)
2012-02-03 20:23 UTC, Christopher Neufeld
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Neufeld 2012-02-03 20:23:24 UTC
Created attachment 68473 [details]
Screen shot of the bug.  Mouse pointer (not visible) is in the centre bottom konsole

Version:           unspecified (using KDE 4.8.0) 
OS:                Linux

I use the "dim inactive" effect, with "apply effect to groups" turned off.  My focus rule is "focus under mouse", and I typically have 5 separate konsole windows on my primary desktop.  When I move the mouse over a konsole, that one should brighten and the others should dim.  The result, though, is very hit and miss.  Sometimes two konsole windows are bright, sometimes just the one, and the entire desktop has sharp-edged shadow regions drawn over it.

I'm using the NVidia 280.13 driver on a GeForce GTS 450 card.  The bug also appears on a GeForce 9600M GT card, same driver.

Reproducible: Always

Steps to Reproduce:
Open several Konsole windows.  Set the focus policy to "focus under mouse".  Turn on "dim inactive", and verify that "apply effect to groups" is not checked.  Move the mouse between konsole windows for a few seconds, and the problem is obvious.

Actual Results:  
Some windows are partially dimmed, regions of the desktop far from the active konsole window have shadows across them.  Screenshot is attached.

Expected Results:  
The window under the mouse pointer should be bright, all others should be dim, with no visible shadow artefacts.

This problem did not appear in the SC 4.7 build.  Between the two builds I did not change the NVidia driver, the problem appeared immediately when I switched from 4.7 to 4.8.
Comment 1 Thomas Lübking 2012-02-03 21:31:19 UTC
Not reproducable.

a) which backend and does it matter ("kcmshell4 kwincompositing", 3rd tab)
b) which graphicssytem and does it matter (try "kwin --replace --graphicssystem <system> &" <system> being either "native" or "raster"
c) is konsole an important factor? Does it happen if you run "konsole --nofork --notransparency" to run konsole
d) it's probably not important but are the konsoles individual processes or different windows of one process (check "ksysguard")
e) does it happen with other decorations? (try "kde2" or "plastik")
Comment 2 Christopher Neufeld 2012-02-03 22:42:42 UTC
a) Happens with both OpenGL and XRender.
b) Happens with both "native" and "raster" graphicssystem
c) No, it happens with multiple emacs windows.  I also tried, on one desktop, putting up three solitary windows, ones that have no group mates.  A single emacs window, the only one on any desktop, a single amarok window, and a single ksudoku window.  The bug took longer to manifest, but by running the mouse back and forth between windows for long enough, I was able to get the shading effect.  When I turned on "apply effect to groups", the bug still did not appear in this context.
d) The konsoles are different windows of a single process, and that process has two running threads.
e) The problem happens with both kde2 and plastik decorations.
Comment 3 Christopher Neufeld 2012-03-28 02:28:03 UTC
I upgraded to the NVidia binary driver version 295.20, the bug is still present.
Comment 4 Thomas Lübking 2012-03-28 14:23:59 UTC
Please provide some addition details on your focus settings:
- autoraise?
   - delay?
- focus delay?
- Does it also happen with "focus follows mouse" and / or focus strictly under mouse?
- Do you have to change the focus quickly, slowly or does it not matter at all?
Comment 5 Christopher Neufeld 2012-03-28 14:51:45 UTC
I do not have autoraise active.  There is no focus delay.  The problem also appears with both "focus follows mouse" and "focus strictly under mouse".  When I move the mouse very slowly between windows, I still see the bug.  It takes longer to manifest, but I believe that is just because I do fewer focus transitions per unit time.

There's no indication of any problems in the .xession-errors log.  All that is reported is a KNotify::event with increasing event numbers and ref=0, every time the focus changes.

I've been moving my mouse around and observing behaviour, trying to glean additional details.  This might help.

I move to a virtual desktop with no windows in it, other than a few plasmoids on the surface.  I open a new konsole window, the only one on this virtual desktop (though there are still my usual 5 konsole windows on another virtual desktop), and the control panel.  The windows are overlapping.  I move the mouse back and forth between them, sometimes moving onto the wallpaper, with either the konsole or the control panel lying above the other.  The bug does not appear.  The window under the mouse pointer is always undimmed, the window not under the mouse pointer is always properly dimmed.

Now, I open a third window on this virtual desktop.  I tried an 'xv' window for one test, and the kmix mixer window for a second test.  All three windows are kept non-overlapping.  I start moving the mouse around between windows.  The bug appears.  The first sign of it is usually that a window that the mouse leaves fails to dim, or dims only partially.  The window that the mouse enters is always un-dimmed, but the window that it left may still at the same brightness, or may stop somewhere before it reaches its normal dimmed state.  Those overlapping boxes and shadows in the original screenshot appear to be the fully-dimmed state of nearby windows, but the dimmed shadows are bigger than the nearby windows that cast them.  Also, plasmoids underneath a window that failed to fully dim can leave fully-dimmed blocks in it.

In fact, all of the artefacts that I have seen with this bug can be explained by assuming that, when at least three windows are present on the virtual desktop, a particular window might fail to dim completely, and nearby dimmed windows and plasmoids can cast fully-dimmed shadows onto the partially-dimmed window.  These shadows are 39 to 40 pixels outside the frame of the window that casts this shadow.
Comment 6 Thomas Lübking 2012-03-28 19:01:22 UTC
Sorry, I'm stupid - i depends on the animation speed.
Thus is basically suffers from the same weakness as the translucency effect to not be able to handle multiple contradicting transitions :-(

Good news is that we'll reset it (possibly JS based) on the AnimationEffect class which was explicitly designed to handle an infinite amount of random animated transitions at once.

Bad news is that that will not happen during 4.8.

I'll check for a hotfix, but 4.8.2 is tagged tomorrow, so please don't be too eager :-(
Comment 7 Christopher Neufeld 2012-05-24 02:57:12 UTC
I just rebuilt from a git checkout on 2012-05-22, and the bug is essentially gone.  If I really work at it, I can get a few minor shadows in one window, but as soon as the window gets focus, it's cleaned up, unlike when this bug was first reported, when the artefacts accumulated over time until the screen was annoyingly cluttered.

It has reached the point where I can turn off the "apply to groups" option.  While not completely fixed, it works well enough for me.

I'm not going to close the bug, in case there's more being done, but I'm satisfied with it now.
Comment 8 Martin Flöser 2013-05-21 06:55:49 UTC
Let's set to worksforme for the time being. Effect should be rewritten some day with JavaScript, that would fix even the last remaining issues.