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.
Please provide the output of "qdbus org.kde.kwin /KWin supportInformation" and see whether this also happens with deactivated blur effect
Created attachment 74062 [details] KWin Support Information
(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.
What fglrx version do you use? If it's recent (8.973/8.98 or later) try "KWIN_DIRECT_GL=1 kwin --replace&"
(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 ^_-
Not the least, but aticonfig --get-pcs-key=LDC,ReleaseVersion does. In "kcmshell4 compositing", "all effects", blur config, please uncheck "safe intermediate rendering results"
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?
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.
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?
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.
then i hope someone comes by and knows how to do that stuff :)
Thomas, could you elaborate on how the blend function is wrong?
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
If you guys need more information or want me to test something, please do tell.
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.
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?
resolves this issue, but causes ugly edge artifacts on regular updates of a blurred region :-(
(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!
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 ;-)
ohh no problem, i'm already happy that someone knows how to fix things like this :)
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.
*** Bug 314817 has been marked as a duplicate of this bug. ***
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.
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.
> @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.
(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.
(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.
*** Bug 325959 has been marked as a duplicate of this bug. ***
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
*** Bug 328071 has been marked as a duplicate of this bug. ***
*** Bug 328951 has been marked as a duplicate of this bug. ***
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".
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".
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 ;)
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
*** Bug 330853 has been marked as a duplicate of this bug. ***
*** Bug 334677 has been marked as a duplicate of this bug. ***
*** Bug 334911 has been marked as a duplicate of this bug. ***
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
*** Bug 342761 has been marked as a duplicate of this bug. ***
*** Bug 354890 has been marked as a duplicate of this bug. ***
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)?
does this still happens? since http://commits.kde.org/kwin/ca1354e8afd9242299b16389523e97392df8bed0 doesn't seem to happen anymore for me
(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.
I can reproduce this on KDE Neon 5.10.3
Is this bug still relevant? Blur effect is no longer doing doCachedBlur.
Setting to unmaintained as the functionality got dropped in 5.13.