Bug 262578

Summary:	Desynchronized blur effect (it takes nearly a second to blur background fonts and images)
Product:	[Plasma] kwin	Reporter:	Martín Cigorraga <msx>
Component:	compositing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	clee, gvvsss, linux.nerdy.kid
Priority:	NOR
Version First Reported In:	4.3.2
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Martín Cigorraga 2011-01-08 20:44:29 UTC

Version:           4.3.2 (using KDE 4.5.5) 
OS:                Linux

Dear Devs:

Lately I found the blur effect it isn't activated from the very moment I click Kickoff or for instance the Notification icon or any other tool that uses transparency.

Usually the blurring happens after half-to-one second after the transparent region is shown, are you aware of this? This is a normal behaviour (i.e. 'it's not a bug, it's a feature!', etc.)? In the last case, shouldn't blur effect be instant?

Thank you very much for your generous work and time, I really enjoy using KDE SC =)

Reproducible: Always

Steps to Reproduce:
Activate any transparency system tool from the tray bar, the Kickoff or any other application which uses transparency.

Actual Results:  
Blur effect will be 1 second (or so) late.

Expected Results:  
It should be instant, I mean the user should not see the change.

OS: KDE SC 4.5.5.1 on Parabola GNU/Linux (Arch Linux %100 Libre)
CPU: QuadCore 8400 2.66mhz, 4gb RAM
Video: ATI RADEON HD 5750 1 gb using Catalyst 10.10 (privative module)

Comment 1 Thomas Lübking 2011-01-08 22:24:42 UTC

blurring is not enabled during window transforming effects (like probably the slide-in effect of the kickoff menu) for causing visual glitches* and performance reasons - is this what you mean?

*the blur filter can under some circumstances not predict where or how the window appears.

Comment 2 Martín Cigorraga 2011-01-09 02:44:05 UTC

Hi Thomas, thank you for replying so fast.

I really didn't know how Transparency effect works but based on your explanation I see that it isn't a bug, is the way it's designed.

Anyways, it would be awesome if you can find a way to make this blur effect smoother, sadly I don't have any C/Qt skills so I can't help you on this one =(

Once again, thank you all for your great work in KDE SC!
Wish you an _awesome_ 2011.

(I close this report with a RESOLVED / WONTFIX but please change the status as you see it fit)

Comment 3 Thomas Lübking 2011-01-09 15:10:58 UTC

*** Bug 262663 has been marked as a duplicate of this bug. ***

Comment 4 Martin Flöser 2011-01-29 12:29:59 UTC

*** Bug 264726 has been marked as a duplicate of this bug. ***

Comment 5 Siva 2011-01-29 12:39:51 UTC

I do not know whether I should comment it here or not, but as my bug report 264726 (https://bugs.kde.org/show_bug.cgi?id=264726) was issued a closed status and duplicate of this bug.

I would just like to know whether compiz like behaviour is completely impossible to achieve with kwin 

or

Kwin simply does not try to make it smooth by nature?

Comment 6 Martín Cigorraga 2011-01-29 16:41:34 UTC

Hi devs, people:

After further research I found this specially annoying bug is triggered when some special KWin's effects are enabled; so far I found "Wabby windows" (Ventanas gelatinosas) and "Scale out" will make Kickoff's transparency (as well as other system transparent dialogs) specially unreliable.

Cheers.

Comment 7 Thomas Lübking 2011-01-29 16:55:17 UTC

see comment #1

the current blur effect relies on a list of "to-be-blurred" rects assigned to the window to not waste time on blurring obscured regions - it won't blur anything else.

When to window shape or position is transformed w/o the blur filter knowing about, it cannot re-transform the "to-be-blurred" region with it, so currently this is not possible.

We'll likely have to move the blur effect into the render core so it knows about those transformations what /might/ happen alongside other changes on the renderstack for 4.7.

Comment 8 Chris Lee 2018-11-05 02:43:15 UTC

Any chance this might be worth revisiting with the new (much faster) blur?

Comment 9 Martin Flöser 2018-11-05 08:02:27 UTC

Several effects already gained support for blur.