Please report Plasma 5 issues to plasmashell product instead of plasma product.

Not reproducable here. I remember it being an issue long ago, but it was fixed (IIRC by myself, even). Puzzled.

Confirmed.

Assigning to kwin which handles the blur effect (which is what's getting lost)

ftr: it looks blurring on the screenshot.

i doubt this is an actual "bug".
the breeze theme is just hardly transparent and panels are faded out on desktop cube. since transparency it has a stronger absolute impact on opaque items.

from the OP, i'd rather read: "i want back air!"?

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

I think the problem here is that the contrast effect is not applied here. i wanted to file a bug about it but i found that one. Basicly panel looses contrast effect while present windows, cube, trasitioning from one desktop to the other.

sounds related to #341926

Question:
--------------
The contrast effect is provided to "Improve contrast and readability behind translucent windows"

It does so by "injecting" a composition with (something that looks like) a plain color (probably usually white) where the normal (degenerated) P&D SrcOver composition

    a*ggg + rgb*(1-a)

is replaced by

   rgb*a*ggg + rgb*(1-a)

ie. by multiplying the destination (into the plain color injected source)


Self-multiplication is a common approach to increase contrast, but I do not understand why the translucent widget base *has* to be moved into the effect.
Yes, that's required for the exact formular, but the effect could simply multiply (with a intensity controlled by the client, for all I care) the destination onto itself and then have the normal porter & duff SrcOver with the (less) translucent window.

        a*ggg + rgb*rgb*(1-a)

This is oc. not the exact same result, but will nevertheless result in contrast improvement, does not require "yet another plasma theme variant" (I assume it does?) and should be far more robust (in case of failure, the contrast is not enhaced, but because of the "normal" plasma theme everything will remain readable and we also can still skip the transformation in transitional states)

(Instead of a "dumb" -and naturally darkening- mulitplication, the effect could also perform a stretch of the colorspace, eg. some sigmoid transformation)

I stumbled upon this issue without using the cube.
For me, switching desktop with slide works fine until "present windows" effect has been used at least once.

Behavior:
- fresh start of KDE, background contrast and blur effects enabled
- slide from desktop 1 to desktop 2, no issue observed in panel
- use  "present windows" effect (i.e. calling it from keyboard shortcut)
- slide from desktop 1 to desktop 2 now shows the issue, background contrast is absent while sliding and works again once sliding is complete (same issue that has been reported)
- issue will stay until kwin is restarted with kwin_x11 --replace &
- after restart, issue no longer shows until the present windows effect is used again

Running:
kwin-5.3.1, plasma-desktop-5.3.1 on Arch Linux with NVIDIA driver

Maybe this commit fix also this bug ?

http://commits.kde.org/plasma-framework/d65c0ed1d07b4fb09643c9401a6697db1282d89e

(In reply to jeremy9856 from comment #10)
> Maybe this commit fix also this bug ?
> 
> http://commits.kde.org/plasma-framework/
> d65c0ed1d07b4fb09643c9401a6697db1282d89e

I consider that as very unlikely.

Kai or Marco - or anyone who can answer this:
why is painting the panel background performed in the compositor in the first place?

This theoretically (before Kais patch) raises the demand on plasma theme variants by 2, is not very robust (readability of sth. that promises to increase the contrast depends on IPC) or efficient and forbids to bypass the effect in transient states (when invoking certain detail lowering or fast moving effects)

On technical details why I doubt that doing this *just* (in case that's the idea) to raise the contrast of the overlaid destination, please see comment #8.

The panel background is an SVG painted by Plasma, KWin applies a contrast effect behind it like it did with the blur effect. Why that is, I don't know, I suppose because the window itself doesn't know what's behind it?

(In reply to Kai Uwe Broulik from comment #13)
> The panel background is an SVG painted by Plasma, KWin applies a contrast
> effect behind it like it did with the blur effect. Why that is, I don't
> know, I suppose because the window itself doesn't know what's behind it?

My "problem" here is that the plasma theme for the contrast effect enabled is vastly transparent and then the contrast effect gets the background color of the panel passed and merges it into the "contrast" texture.
That seems somehow silly - at least I don't understand why it's done this way.

The effect is required to increase the contrast of the destination (ie. the region behind the window), but this has nothing to do with the source (the panel/background) at all
At most the panel (background color) could be used to control how much contrast increment is desired, but why would one not just say "increase contrast by 20%" instead?

I am still experiencing this on Plasma 5.10.3, Qt version 5.9.1. Is there any update on this bug? It really breaks the polished look of Plasma when switching desktops.

There is no update and I consider it as unlikely that this bug will get fixed any time soon. I'm sorry, but there are more important bugs to fix.

@Martin

I propose to mark this bug as WONTFIX because we can't use the blur effect and the background effect with the desktop cube effect (also flip switch, cover switch, cube slide, glide, and so on).

The only viable solution is to make panels such way that it doesn't matter whether background is blurred, something what Windows 7 did.

For example, during the "fly" in/out animation, background behind windows is not blurred and most people don't notice that. Same with the Flip 3D: https://upload.wikimedia.org/wikipedia/ru/1/19/Windows_7_Flip_3D.jpg

Setting to worksforme