Bug 241557

Summary: Zoom effect conflicts with other desktop effects like Blur
Product: [Plasma] kwin Reporter: AGui <audardg>
Component: effects-variousAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: normal CC: airdrik, dontarius, eugenio89, fabian, illumilore, ivo, jtcmh13, kokoko3k, nitanovidiu, qbert, RaitaroHikami, rjbrother2, simonandric5, sirmentio123, s_chriscollins, thomas, wengxt
Priority: NOR    
Version: 5.14.1   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Screenshot showing the offset blur area and left-lover image trail
Screenshot of the zooming effect creating artifacts for the blur effect

Description AGui 2010-06-12 16:01:09 UTC
Version:           SVN (using Devel) 
OS:                Linux

Hi,
I'm running KDE 4.5 Beta 2 on openSUSE 11.2. When using the zoom effect from Kwin, there is a bug with Blur (in the Calendar plasmoïd for example).

I also noticed that the windows' preview in the Task Manager are also buggy with the zoom activated.

Reproducible: Always

Steps to Reproduce:
Enable Zoom and Blur in KDE System Settings.
Zoom the deskop ("Meta + +" by default)
Show the calendar by clicking on the clock

Actual Results:  
The background of the calendar is not blurred but black.
When you move the mouse, the blur effect may apply to part of the calendar.

Expected Results:  
The Blur effect should apply the same way whether or not the zoom effect is activated.

I use the Air desktop theme from KDE 4.5 Beta 2.
Comment 1 Eric Francis 2010-09-03 05:36:35 UTC
I'm not sure if this is the same issue, but I'm also seeing some problems with Blur + Zoom, namely that the area being blurred 'moves' with (counter to) the zoom area and leaves remnant image traces behind (see attached image).  
KDE 4.5.1 on PCLinuxOS (using latest svn bespin style with ARGB and blur enabled)

To reproduce:
1. Activate Blur and Zoom KWin effects
2. Open a window that shows the Blur effect
3. Zoom in
4. Pan around the desktop

Actual results:
The blurred area moves in the opposite direction as the mouse relative to the window, leaving an image trail behind.

Expected Results:
The blurred area remains fixed to the window (i.e. moves with the window as the mouse and zoom area moves)
Comment 2 Eric Francis 2010-09-03 05:38:11 UTC
Created attachment 51254 [details]
Screenshot showing the offset blur area and left-lover image trail
Comment 3 Thomas Lübking 2011-07-02 18:54:18 UTC
*** Bug 265024 has been marked as a duplicate of this bug. ***
Comment 4 Antonio Orefice 2011-09-13 17:07:28 UTC
Another way to reproduce (kde 4.7):
activate blur plugin
make sure area unther the bottom panel is blurred
zoom in
note that the lower part of the screen is blurred, even if the panel is not visible anymore.

** so: zoom plugin does not update the blur aera **
Comment 5 Thomas Lübking 2011-09-13 19:06:37 UTC
(In reply to comment #4)
> ** so: zoom plugin does not update the blur aera **

FTR: "And should not."

The blur area is set by the clients, manipulating it from an effect would partially not work (broken by interim client updates) and in doubt leave a wrong state.

The blur effect needs to recalculate the area with the zoom transformations so in doubt must be ensured to be invoked after zooming has manipulated the data and/or the zoom effect must export the transformation globally.
Comment 6 Ovidiu D. Niţan 2012-03-14 22:28:22 UTC
Something new about this little bug? Or it will catch KDE 5.0?
Comment 7 Martin Flöser 2012-03-15 07:01:56 UTC
(In reply to comment #6)
> Something new about this little bug? Or it will catch KDE 5.0?
Comments like these do not really raise the motivation of the developer to work on the bug. We have enough open bug reports we can choose from for working on them. At the time of this writing there are ~300 open bug reports for KWin.

For a user it is very impossible to judge whether a bug is "little" or "heavy", for a user it is impossible to know how long it will take to fix this bug.
Comment 8 Ovidiu D. Niţan 2012-03-15 07:28:50 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Something new about this little bug? Or it will catch KDE 5.0?
> Comments like these do not really raise the motivation of the developer to
> work on the bug. We have enough open bug reports we can choose from for
> working on them. At the time of this writing there are ~300 open bug reports
> for KWin.
> 
> For a user it is very impossible to judge whether a bug is "little" or
> "heavy", for a user it is impossible to know how long it will take to fix
> this bug.

Sorry for that, I was just curious about the state of this bug. I found it last days and, trying to submit a bug about it, I found this bug report and the last activity beign on september last year. I understand that nobody is paid to fix bugs here, I'm also working on some open-source project without beign paid, but I just wanted to bring this bug into attention.
Comment 9 Martin Flöser 2012-08-05 06:10:33 UTC
*** Bug 279566 has been marked as a duplicate of this bug. ***
Comment 10 AGui 2014-05-17 11:45:43 UTC
This bug is still valid for KWin 4.96. On the Neon 5 iso, there is a plama panel on the bottom. If you zoom in, a white rectangle stays at the bottom of the screen even when the panel is not in the zoomed area.
Comment 11 Martin Flöser 2014-07-12 15:57:22 UTC
*** Bug 337398 has been marked as a duplicate of this bug. ***
Comment 12 Martin Flöser 2014-12-02 07:18:19 UTC
*** Bug 341475 has been marked as a duplicate of this bug. ***
Comment 13 Martin Flöser 2016-04-13 06:00:07 UTC
*** Bug 361561 has been marked as a duplicate of this bug. ***
Comment 14 Thomas Lübking 2016-06-12 12:46:19 UTC
*** Bug 364199 has been marked as a duplicate of this bug. ***
Comment 15 Thomas Lübking 2016-06-12 12:46:31 UTC
*** Bug 347849 has been marked as a duplicate of this bug. ***
Comment 16 Martin Flöser 2016-11-10 06:42:57 UTC
*** Bug 372264 has been marked as a duplicate of this bug. ***
Comment 17 Antonio Orefice 2016-11-10 07:24:57 UTC
Any particular reason this bug is still marked as UNCONFIRMED (!?)
Comment 18 Martin Flöser 2016-11-10 07:30:30 UTC
(In reply to Antonio Orefice from comment #17)
> Any particular reason this bug is still marked as UNCONFIRMED (!?)

This is a common confusion among users. The state has no influence on the bug at all. For us fixing bugs it's not a question of whether the bug is in unconfirmed or confirmed state.
Comment 19 Antonio Orefice 2016-11-10 07:31:34 UTC
Yes, yes, i did not mean that.
I really mean just what i asked :)
Comment 20 Martin Flöser 2016-11-10 07:38:06 UTC
It's unconfirmed because we don't care about the state. We don't go into the bugs and mark them as confirmed. It's as simple as that: it does not have any meaning.
Comment 21 Qbert 2017-03-23 19:10:26 UTC
This bug is still present, and annoying, in 5.9.3.
Comment 22 Martin Flöser 2017-08-06 14:48:32 UTC
*** Bug 383138 has been marked as a duplicate of this bug. ***
Comment 23 Brandin Starliper 2018-10-21 17:05:24 UTC
Created attachment 115809 [details]
Screenshot of the zooming effect creating artifacts for the blur effect
Comment 24 Brandin Starliper 2018-10-21 17:06:00 UTC
I can confirm that this causes issues still in 5.14 to an extent, I'd like to keep my desktop pretty while also keeping my eyesight. The problem with the blur effect is that so long as there's some sort of transparency, there seems to be some visual artifacts that I'm not sure how they come to be.
Comment 25 RaitaroH 2018-11-12 07:00:21 UTC
(In reply to Brandin Starliper from comment #24)
> I can confirm that this causes issues still in 5.14 to an extent, I'd like
> to keep my desktop pretty while also keeping my eyesight. The problem with
> the blur effect is that so long as there's some sort of transparency, there
> seems to be some visual artifacts that I'm not sure how they come to be.

I can also confirm. Doesn't seem to matter if it is widget, terminal etc. Also I can see my background image even after I switched it, but is like a combo of the old image and the newer one, quite weird.
Comment 26 AGui 2022-05-29 11:06:00 UTC

*** This bug has been marked as a duplicate of bug 447670 ***