Bug 422596 - Discover window's content is transparent at startup on X11
Summary: Discover window's content is transparent at startup on X11
Status: CONFIRMED
Alias: None
Product: Discover
Classification: Applications
Component: discover (show other bugs)
Version: 5.23.4
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Dan Leinir Turthra Jensen
URL:
Keywords:
: 427398 450936 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-06-07 21:25 UTC by Lua
Modified: 2022-10-21 16:41 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
discover bug (874.99 KB, image/png)
2020-06-07 21:25 UTC, Lua 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Lua 2020-06-07 21:25:36 UTC 
Created attachment 129128 [details]
discover bug

SUMMARY


STEPS TO REPRODUCE
1. Open Discover

OBSERVED RESULT
Window's content is transparent/glitched.

EXPECTED RESULT
Make the content to not be transparent. Maybe adding a "loading" text is a solution.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Kubuntu 20.04
(available in About System)
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8

ADDITIONAL INFORMATION
Comment 1 Lua 2020-06-07 21:26:31 UTC 
Also, maximizing the window after opening Discover makes the shadow of the previous window state to appear.
Comment 2 Nate Graham 2020-06-11 04:49:35 UTC 
Argh, I thought we fixed this! Alas, I too can reproduce with current git master.
Comment 3 Patrick Silva 2020-11-02 22:01:44 UTC 
*** Bug 427398 has been marked as a duplicate of this bug. ***
Comment 4 Lua 2021-04-28 23:08:41 UTC 
Doesn't seem to be happening anymore in 5.21.4. Anyone can confirm?
Comment 5 Felipe Kinoshita 2021-04-29 00:57:14 UTC 
Not happening in 5.21.4 for me.
Comment 6 Patrick Silva 2021-04-29 01:29:52 UTC 
it's still happening on my system, but I can't reproduce consistently.

Operating System: Arch Linux
KDE Plasma Version: 5.21.4
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2
Graphics Platform: X11
Comment 7 Nate Graham 2021-04-29 02:29:12 UTC 
Can reproduce on git master.
Comment 8 Lua 2021-06-06 03:31:29 UTC 
I don't have this anymore in 5.21.5. Maybe this is related to the loading screen.
Comment 9 Nate Graham 2021-06-07 13:33:34 UTC 
Hmm, now it's not happening for me either. Seems random...
Comment 10 Aleix Pol 2021-06-17 00:02:56 UTC 
FWIW, wayland fixes it.
Comment 11 Nate Graham 2021-06-17 14:37:14 UTC 
Indeed, I can't reproduce the issue at all in the Plasma Wayland session.
Comment 12 Nate Graham 2021-12-13 18:22:54 UTC 
Confirmed on X11, seems fixed on Wayland.
Comment 13 Patrick Silva 2022-02-28 20:23:42 UTC 
*** Bug 450936 has been marked as a duplicate of this bug. ***
Comment 14 Aleix Pol 2022-10-21 16:17:28 UTC 
Can somebody test it on their system without "lib64/plugins/bearer/libqnmbearer.so"?

*Boring explanation of what I think is happening here follows*

This was big part of my conclusion last I looked into this problem, I did submit a patch to Qt to make networkmanagement introspection less aggressive at startup but it seems like there's a whole new infrastructure in Qt 6 so it never went in.

For context, what's happening is:
- Qt says hey, give me a window, I'll draw some stuff.
- Then as it prepares, we do things, some of them blocking* (oh no!)
- then we render the contents

* one of the blocking thing that happens is setting up the network management system internally to check if we are connected online. It's not done in the best of ways (hence their refactoring for Qt 6).

I believe the problem we are seeing here is those blocking things. I do think it also happens on Wayland, only there the compositor reacts in a more graceful way.

I am pretty sure in Qt 6 this will be better overall.
Comment 15 Aleix Pol 2022-10-21 16:41:52 UTC 
Something that would also help me improve this issue, would be to test separately with different backends and see if there's one (or a subset combined) that feels especially bad.