Bug 307112 - Blur effect: doCachedBlur() is broken for non opaque windows (at least)
Summary: Blur effect: doCachedBlur() is broken for non opaque windows (at least)
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: 4.11.4
Platform: unspecified Other
: NOR normal with 4 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/121...
Keywords:
: 314817 325959 328071 328951 330853 334677 334911 342761 354890 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-09-20 17:31 UTC by Mark
Modified: 2018-06-01 15:19 UTC (History)
24 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.2.0
mgraesslin: ReviewRequest+


Attachments
KWin Support Information (10.22 KB, text/plain)
2012-09-20 21:19 UTC, Mark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark 2012-09-20 17:31:56 UTC
Hi,

I don't know if this occurs in more places, but i noticed this issue in the tooltips from both system settings and dolphin.

What happens is that as soon as the tooltip is starting to fade out, some area instantly vanishes (without fading) while the rest of the tooltip that does remain visible is just fading out the way it's supposed to.

I couldn't make a screenshot of this easily, but i found a video in which the same issue is also visible: http://vimeo.com/49618818

In that video, look at 1:31 where Alex Fiestas changes to the system settings and you see a hover tooltip. Pay very careful attention to the closing animation of that tooltip since that's where you see the above described "artifact".

Reproducible: Always

Steps to Reproduce:
1. Go to system settings (or dolphin)
2. Hover over anything that shows a tooltip
3. note how the tooltip vanishes. A small area instantly vanishes while the rest simply fades out.
Actual Results:  
A small area instantly vanishes while the rest simply fades out.

Expected Results:  
The tooltip should just (in it's entirety) fade out without artifacts.

Well, i am running on AMD hardware with all settings as the default ones from archlinux and that's where i'm observing this issue. I haven't tried the radeon or vesa driver.
Comment 1 Thomas Lübking 2012-09-20 21:14:21 UTC
Please provide the output of "qdbus org.kde.kwin /KWin supportInformation" and see whether this also happens with deactivated blur effect
Comment 2 Mark 2012-09-20 21:19:50 UTC
Created attachment 74062 [details]
KWin Support Information
Comment 3 Mark 2012-09-20 21:23:05 UTC
(In reply to comment #1)
> Please provide the output of "qdbus org.kde.kwin /KWin supportInformation"
> and see whether this also happens with deactivated blur effect

Ohh, that's interesting! I actually fixed the blur behind in those apps mentioned and back then it didn't seem to cause any issues with blur. It worked just fine. Odd.

Either way, if i disable blur the issue is indeed gone. But considering it did work for me in the KDE 4.7.x cycle i can't help but thinking that the blur effect changed. Also, when blur is enabled the animation seems to go a bit stuttering while it's just fluid without it.

No, my card isn't ancient.. 6870 so it is more then powerful :)
Also attached the support info.
Comment 4 Thomas Lübking 2012-09-21 19:13:16 UTC
What fglrx version do you use?
If it's recent (8.973/8.98 or later) try "KWIN_DIRECT_GL=1 kwin --replace&"
Comment 5 Mark 2012-09-21 19:23:13 UTC
(In reply to comment #4)
> What fglrx version do you use?
> If it's recent (8.973/8.98 or later) try "KWIN_DIRECT_GL=1 kwin --replace&"

Hi,

I'm running the 12.8 driver. I don't know which 8.xxx that is, but you probably do ;)
I also tried to reproduce the same with KWIN_DIRECT_GL=1 as you said and i can still see the exact same issue.

It is very noticeable in Dolphin (with and without that define).

Also, i keep seeing a lot of these messages:

kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadDamage [DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x6c002f3" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadDamage [DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x6c00336" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadDamage [DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x6c00341" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadDamage [DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1dc" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadDamage [DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x6c00357" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadDamage [DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1dc" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x7400255" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadDamage [DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1c00335" ) 

along with those sometimes:

kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x740032d" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x740032e" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x740032f" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x7400330" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x7400331" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x7400332" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x7400333" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x7400334" ) 
kwin(18227) KWin::x11ErrorHandler: kwin: X Error ( "error: BadPixmap [4], request: X_FreePixmap[54], resource: 0x7400335" ) 

Yeah, i happen to be running in debug mode at the moment ^_-
Comment 6 Thomas Lübking 2012-09-21 19:27:54 UTC
Not the least, but
     aticonfig --get-pcs-key=LDC,ReleaseVersion
does.

In "kcmshell4 compositing", "all effects", blur config, please uncheck "safe intermediate rendering results"
Comment 7 Mark 2012-09-21 19:35:53 UTC
Oke, the driver is: 8.872-110707b-122669C-ATI

unchecking "safe intermediate rendering results" results in a perfectly working blur :) It's smoother then before and doesn't show any artifacts. So that makes it "fixed" for me, but i do wonder.. should that option be ticked by default? And what does it do anyway?
Comment 8 Thomas Lübking 2012-09-21 19:44:07 UTC
cache, make things faster (probably does, but just doesn't look so)

Blurring used to be disabled during transitions then and got enabled after Philip spent a lot of time to make things faster.

However the doCachedBlur() function looks rotten - it does esp. not use the shader to set the opacity and the glBlendFunc seems (is) wrong (since 4.6.3 or so)

It's enabled by default but apparently broken.
Comment 9 Mark 2012-09-21 19:47:05 UTC
Then might i suggest to disable it for now and push that in KDE 4.9.2 and 4.10 till it's working properly?
Comment 10 Thomas Lübking 2012-09-21 19:52:13 UTC
I countersuggest to use the proper glBlendFunc and set the correct shader uniform, ie, "fix it" - there's still a week till 4.9.2 tagging.
Comment 11 Mark 2012-09-21 20:09:33 UTC
then i hope someone comes by and knows how to do that stuff :)
Comment 12 Fredrik Höglund 2012-09-27 15:56:19 UTC
Thomas, could you elaborate on how the blend function is wrong?
Comment 13 Thomas Lübking 2012-09-27 16:33:53 UTC
from about 4.6.3 on modulated GLTexture rendering (w/o shaders) required

glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
alongside
glColor4f(myAlpha, myAlpha, myAlpha, myAlpha);

blending w/
glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );

simply got you the opaque texture, so i thought this would likely extrapolate to GL_CONSTANT_ALPHA (for the same outcome) but that does not have any impact on this and the bug is not reproducible in master. There's some flicker when the window below the blurring one is updated during the fadeout, but the fadeout itself works - so there must be sth. entirely else.
Currently recompiling 4.9
Comment 14 Mark 2012-09-27 16:47:13 UTC
If you guys need more information or want me to test something, please do tell.
Comment 15 Thomas Lübking 2012-09-27 16:53:35 UTC
running 4.9 again - the opaque texture is gone.
Sorry, don't ask me why - i restarted kwin a dozen times back then and it happened _every_ time (full opaque texture) -> heisenbug (but could also have been the nvidia driver, i updated to 304.51 interim

what remains is the wrong repaint area as seen in the bug, slowing down the fade-out, it seems only the very last updated tile is visually invalid.
Comment 16 Thomas Lübking 2012-09-27 22:02:14 UTC
The troublemakers are lines 619 & 317

doCachedBlur() usually reduces the damagedRegion to an empty region

619: it->damagedRegion -= validUpdate;
This usually ends up with an empty region

317: data.clip |= blurArea - expand(it->damagedRegion);
What apparently makes the subtrahend too small, thus the clip too big.

Omitting either of those lines resolves the artifacts, but i guess the proper solution would be to schedule 619 behind 317, ie. cache the lastValidUpdate and diminish damagedRegion after the next prePaintWindow call - gonna try.

@Philipp
does that make any sense to you?
Comment 17 Thomas Lübking 2012-09-27 22:15:37 UTC
resolves this issue, but causes ugly edge artifacts on regular updates of a blurred region :-(
Comment 18 Mark 2012-09-27 22:45:03 UTC
(In reply to comment #17)
> resolves this issue, but causes ugly edge artifacts on regular updates of a
> blurred region :-(

Ohh, but you're close :)
Good luck!
Comment 19 Thomas Lübking 2012-09-27 22:48:06 UTC
It's become too late anyway - tagging is in about an hour and i'm not even sure whether martin is still awake (not to mention that he _reasonably_ would deny adding any patch that has seen about 5 minutes of testing right before the release ;-)
Comment 20 Mark 2012-09-27 23:21:42 UTC
ohh no problem, i'm already happy that someone knows how to fix things like this :)
Comment 21 Mark 2013-02-11 10:25:52 UTC
Hi,

Meanwhile my hardware setup changed quite a bit. I'm using a Intel CPU now and a Nvidia graphics card so i tested this issue out on that new setup with KDE 4.10.

While blur looks just fine, i still see the exact same issue i saw when reporting this. It's just a lot less visible on nvidia, but it certainly is there. You really have to rapidly move over a tooltip to be able to see it at all, but it's there.

Doing the earlier advice:
> In "kcmshell4 compositing", "all effects", blur config, please uncheck "safe intermediate rendering results"

Is also fixing this on nvidia.

I think you can see this issue more clearly if you slow down the fading out of a tooltip to 5 seconds or so. Is there a config option for that?

I changed the version to KDE 4.10.
Comment 22 Thomas Lübking 2013-02-11 10:56:04 UTC
*** Bug 314817 has been marked as a duplicate of this bug. ***
Comment 23 Nikola Schnelle 2013-03-30 17:06:36 UTC
I think I am seeing the same bug in icon-only task manager tooltips.  Unchecking  "safe intermediate rendering results" or turning off blur effect fixes the problem.

Video: http://www.sendspace.com/file/w6irbj

I see this on KDE 4.10.1, ATI card with latest stable radeon driver and mesa and latest kernel.
Comment 24 Thomas Lübking 2013-09-26 21:07:26 UTC
Lokking at this again

@Martin - were deleted windows supposed to blur at all?
(For it does not seem so and does not happen with unmanipulated uncached blurring either - what in a way makes sense since the client and thus the blur property is gone)

In case the "solution" here would be *very* simple.
Comment 25 Martin Flöser 2013-09-27 08:59:47 UTC
> @Martin - were deleted windows supposed to blur at all?
I would say NO! As deleted windows will be animated in some way the blur is 
disabled anyway.
Comment 26 Fredrik Höglund 2013-09-27 13:57:52 UTC
(In reply to comment #25)
> > @Martin - were deleted windows supposed to blur at all?
> I would say NO! As deleted windows will be animated in some way the blur is 
> disabled anyway.

Fade animations work just fine.
Comment 27 Thomas Lübking 2013-09-27 19:31:59 UTC
(In reply to comment #26)
> Fade animations work just fine.

Yupp (just not alongside a subtle scale ;-)

Also it's not limited to deleted windows.
I can cause the basic problem by placing a blurred window above a video (completely including it) and altering the blurred windows opacity.
The parts that do not overlay the video are always too opaque, might be superimposing.
Comment 28 Thomas Lübking 2013-10-13 12:23:10 UTC
*** Bug 325959 has been marked as a duplicate of this bug. ***
Comment 29 Istvan Rez 2013-10-13 21:35:45 UTC
Hi,
Same issue with Intel. 
hw: Dell E6520 corei7
sw: Kubuntu 13.10 beta  (KDE 4.11.2) 
Screencast video: http://www.linuxklub-debrecen.hu/owncloud/public.php?service=files&t=34a82bbfe95060868a09a23e77b40ad4
Comment 30 Thomas Lübking 2013-11-25 22:49:29 UTC
*** Bug 328071 has been marked as a duplicate of this bug. ***
Comment 31 Martin Flöser 2013-12-18 13:47:11 UTC
*** Bug 328951 has been marked as a duplicate of this bug. ***
Comment 32 Mark 2013-12-18 13:55:17 UTC
A little update regarding this issue. Things seemed to improve greatly in 4.11, but i still see this issue even though barely. It's perfectly smooth if i untick "safe intermediate rendering results".
Comment 33 Dimitris Kardarakos 2013-12-23 19:00:32 UTC
Same issue in Kubuntu 13.10 - KDE 4.11.3.
VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M]
Just to mention that I use the default settings in "Desktop Effects".
Comment 34 Mark 2013-12-23 19:27:32 UTC
Update with hardware and versions.

4.12 shows the same issue.
Tested under:
- AMD (issue visible)
- NVidia (issue visible)
- Intel (issue visible)

At first i thought this could be an AMD related issue since AMD is just pure utter crap when it comes to graphics + linux. But now it seems like some logic in the code could use a bit of fine tuning ;)
Comment 35 Thomas Lübking 2013-12-23 20:23:39 UTC
See comment #16
This is a bug in the effect and "Me too" comments are useless (it's already confirmed)
Just CC yourself to the bug
Comment 36 thisguy642 2014-03-01 18:39:13 UTC
*** Bug 330853 has been marked as a duplicate of this bug. ***
Comment 37 Philipp 2014-05-17 22:02:28 UTC
*** Bug 334677 has been marked as a duplicate of this bug. ***
Comment 38 Martin Flöser 2014-06-24 05:57:46 UTC
*** Bug 334911 has been marked as a duplicate of this bug. ***
Comment 39 Martin Flöser 2015-01-08 08:07:37 UTC
Git commit ca1354e8afd9242299b16389523e97392df8bed0 by Martin Gräßlin.
Committed on 08/01/2015 at 07:44.
Pushed by graesslin into branch 'master'.

[effects/blur] Disable cached blur for deleted windows

This is a kind of workaround for the flicker of fading out windows.
When a window is faded out it is a deleted and can by that be used
as a sufficient solution to work around the problem.
FIXED-IN: 5.2.0
REVIEW: 121909

M  +2    -2    effects/blur/blur.cpp

http://commits.kde.org/kwin/ca1354e8afd9242299b16389523e97392df8bed0
Comment 40 Thomas Lübking 2015-01-12 15:37:54 UTC
*** Bug 342761 has been marked as a duplicate of this bug. ***
Comment 41 Thomas Lübking 2015-11-07 18:26:57 UTC
*** Bug 354890 has been marked as a duplicate of this bug. ***
Comment 42 Thomas Lübking 2015-11-07 18:38:07 UTC
*** Bug 354890 has been marked as a duplicate of this bug. ***
Comment 43 Lastique 2015-11-07 20:15:07 UTC
Since this is an old bug and seems to affect many users regardless of the GPU, maybe the cache should be disabled by default (or just always disabled, until it is fixed)?
Comment 44 Marco Martin 2017-02-17 15:14:37 UTC
does this still happens? since
http://commits.kde.org/kwin/ca1354e8afd9242299b16389523e97392df8bed0
doesn't seem to happen anymore for me
Comment 45 Lastique 2017-02-17 16:41:40 UTC
(In reply to Marco Martin from comment #44)
> does this still happens? since
> http://commits.kde.org/kwin/ca1354e8afd9242299b16389523e97392df8bed0
> doesn't seem to happen anymore for me

That commit didn't fix the problem as I observed the bug after that commit was made (see bug 354890). The bug is not fixed.
Comment 46 mentis.by 2017-06-30 17:55:59 UTC
I can reproduce this on KDE Neon 5.10.3
Comment 47 Vlad Zahorodnii 2018-06-01 06:32:55 UTC
Is this bug still relevant? Blur effect is no longer doing doCachedBlur.
Comment 48 Martin Flöser 2018-06-01 15:19:50 UTC
Setting to unmaintained as the functionality got dropped in 5.13.