The track mouse animation shows a rotating image. It appears that the transparent background of the icon overlay used in this animation is no longer transparent. This used to work correctly (two rotating semi-circles, one black and one white). Now it is one rotating black semi-circle over a rotating black square. Reproducible: Always Steps to Reproduce: 1.Turn on Track Mouse 2. Press the hotkey combination to find mouse 3. Watch the ugly animation. Actual Results: As mentioned above - the animation for showing the mouse is ugly - not rendering correctly. Expected Results: The animation would perform as in the movie from the "Track Mouse" settings page in Desktop Behaviour --> Desktop Effects.
works fine here. Can you please post the output of qdbus org.kde.KWin /KWin supportInformation
Also check /usr/share/kwin/tm_*.png (the used images)
Created attachment 97552 [details] output of "qdbus org.kde.KWin /KWin supportInformation"
When viewing tm_inner.png and tm_outer.png with gwenview they both appear to be correct (partial circles on transparent background).
> Compositing Type: XRender Happens.
nvidia blob? (in doubt attach /var/log/Xorg.0.log)
Created attachment 97558 [details] copy of /var/log/Xorg.0.log
Nope, Broadwell/SNA - not a driver issue. > This used to work correctly Can you provide more information about this? Notably whether this may have "broken" due to the (deliberate?) switch from GL to XRender? Can you confirm it ever worked on the XRender backend in the KF5 based KWin?
OK - so switched Compositor to OpenGL 3.1 and the problem is resolved. Not sure why or how it got set to xRender.
> Can you confirm it ever worked on the XRender backend in the KF5 based KWin? I never looked at these settings before, (compositor), so they would have been set at the default settings. I know that this used to work fine until about two weeks ago. After a system update (I think it was one of the Xorg updates) it broke. When no patches came, I submitted this report. My installation is about one month old. Not sure if it is relevant, but I've got Deepin installed as an alternative DE - would this have broken something?
Means it's likely been broken all KF5 > Not sure if it is relevant, but I've got Deepin installed as an alternative DE - would this have broken something? Nope.
There's something terribly odd here. The alpha channel actually works "somehow", but it seems it's interleaved with the color channels. Blue, red or black show a reasonable alpha, but even a mid gray (160,160,160) with a supposed alpha of 16 is rather opaque (maybe 160?) - and white! Converting the image to QImage::Format_ARGB32_Premultiplied or QImage::Format_RGBA8888 (it's QImage::Format_ARGB32 and I explicitly painted the content to avoid loading issues) has no impact. static xcb_render_picture_t createPicture(xcb_pixmap_t pix, int depth) always takes a depth of 32 and returns the same format (regardless of the image color) On top of that, it looks somewhat related to the composition - yellow on black seems far more opaque than yellow on white, XCB_RENDER_PICT_OP_ATOP instead of XCB_RENDER_PICT_OP_OVER doesn't change that.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
I can confirm that this issue persists for me, regardless of which compositing method I use. Here's what I see: https://i.imgur.com/xXON5lP.gif
Seems like it was because I was using xrender. Since xrender was removed as an option in Plasma 5.23 I don't think this issue will happen again.
marking as `"fixed"`