#174 Flashing of screen portions behind focused app window

[Anonymous]

Originally created by: RedBearAK

@matinlotfali

I have been observing a phenomenon when this effect is installed, on both physical hardware and a couple of virtual machines. Cause or specific circumstances to replicate is unknown, but I have never seen anything like this prior to installing this desktop effect on those systems.

Sometimes I have large portions of the screen, typically around the focused window, start to flash. Rapidly, on occasion, or more slowly.

It's like something gets stuck trying to refresh large portions of the screen over and over again. Doesn't typically seem to affect the foreground window.

Switching window focus has always made it go away. But it can happen again later.

Zenity (a GTK-based dialog app) windows may play a large part in this. I've been testing a personal project a lot that uses Zenity dialog pop-ups. KDE is just one of many desktop environments where I test that, and I've never seen this kind of issue outside of KDE with this rounded corner desktop effect installed.

Can't say for sure yet, but it looks like adding zenity to the exclusion list may mitigate this. Some distros use qarma as a drop-in replacement for the zenity command (seen on OpenMandriva). In those cases it would probably show up in the window list as qarma rather than zenity. Or it might show up as zenity-gtk.

It makes sense to have an exclusion list for windows where the effect may not work well, but the flashing-screen thing should probably have its own solution at some point, if possible. Some people are quite sensitive to that kind of thing, medically.

[Anonymous]

Originally posted by: matinlotfali

I have never tried Zenity. Do you suggest that I run this for testing?

#!/bin/sh

if zenity --question --text="Please press a button."; then
   zenity --info --text="You pressed Yes\!"
else
   zenity --error --text="You pressed No\!"
fi

[Anonymous]

Originally posted by: RedBearAK

@matinlotfali

Well, that does produce some Zenity dialogs. Mostly I just use the info dialog option. My project puts up a dialog which now has quite a bit of text on it. I seem to be able to remove Zenity from the exclusion list and replicate the flashing issue with my own dialogs, but it can take opening 2 or 3 and then closing one before the flashing or black parts of the screen starts.

With the simpler dialogs produced by your example script, it doesn't appear to trigger the issue as easily. Even setting it up on a loop.

Yeah, seems pretty consistent if I open several dialogs (my own) without closing any, and then start closing them one by one, there is almost always some kind of flashing going on. Really seems to happen during the closing of one dialog, which brings another dialog into focus.

OK, no, the window behind the dialog doesn't need to be another Zenity window, but it does seem to make a significant difference if the new window that takes the focus is NOT maximized. Multiple times now I've opened some Dolphin windows (floating) and then one of the Zenity dialogs, closed the Zenity dialog and was left with the Dolphin windows surrounded by black (no flashing in this case). Closing or switching windows/apps refreshed everything, as usual.

To get these particular large Zenity dialogs you'd need to install this project in a KDE VM, but it would convert your keyboard into a state that reacts like using an Apple keyboard on macOS.

https://github.com/RedBearAK/toshy

Then the dialogs are invoked with Shift+Option+Cmd+I,I (the "I" must be double-tapped quickly).

On a typical PC keyboard that's Shift+Meta+Alt+I,I.

It's possible that if you used a large block of text for your dialogs you could get a similar effect. I'm wondering if the smaller dialogs just don't stress the graphics enough to trigger the flashing or black screen sections.

[Anonymous]

Originally posted by: RedBearAK

@matinlotfali

Looks like my guess was correct. If you splice in a very large block of text with the dialogs, you will have much better luck possibly seeing this issue, just like with the dialogs my app produces.

Oh, and put windows of some kind behind the dialogs, that are not maximized to fit the screen.

Screen res is physically 2560x1440 (iMac12,2), but using scaling of 150% right now, so about 1080p(?) effective. I've also seen it with VMs on a laptop, with the VM res at the native 1080p of the laptop screen and no scaling applied in the VM. The host is Fedora GNOME on the laptop, the iMac is running Tumbleweed, just updated today, and KDE 5.27.10.

The laptop is all AMD with only integrated graphics, and 3D acceleration and OpenGL were enabled in the VM settings.

[Anonymous]

Originally posted by: RedBearAK

@matinlotfali

I'm seeing a similar flashing effect when making dialogs disappear that are opened from icons in the toolbar on Firefox. Sometimes the pop-down dialogs will just flash a couple of times while they go away (like there are multiple updates happening), and sometimes they will get stuck partially gone and just keep rapidly flashing like something is trying to update that part of the screen but keeps failing.

I don't know if it would even be possible to add such dialogs to the exclusion list. They disappear when task switching, so I can't test whether the effect settings dialog would even be able to detect them.

[Anonymous]

Originally posted by: matinlotfali

Sorry, I still can't reproduce this. Is it happening in both Wayland and X11?

[Anonymous]

Originally posted by: RedBearAK

Can't replicate easily after a few minutes trying various things in the Plasma X11 session. I've been staying out of X11 because the scaling does not work the way I wanted it to work.

Tried the context dialogs in Firefox, the Zenity test script, and KDialog windows. No flashing or partial refreshes anywhere that I can see.

So probably something to do with Wayland. I wouldn't know anything about why.

I'm about to update this Tumbleweed system and it may move from Plasma 5 to 6 in a way would only be reversible for a while, with Tumbleweed's automatic boot snapshots.