Flashes black on start for a split second

[dgudim]

Screencast_20240514_090007.webm
When activating kando I get a brief black flash, this is more prominent with system under some load, but also happens when it's idle (for a shorter period though).

I am using kde 6.0.4 / qt 6.7 on arch with wayland

[Schneegans]

Hi there! I cannot reproduce this on my end. Maybe my system is too fast 😜

Anyways, if you are willing to run the latest version from git, you could experiment with different window types. For this, replace this line with either "normal", "desktop", "dock", "toolbar", "splash", or "notification" and then run Kando again with npm start.

Else we could maybe try some other workarounds. Here, a fix using opacity is mentioned. Maybe you could add an opacity: 0 to the list of window properties here and see if the flickering is gone? (The window will most likely stay completely invisible this way, but we will see if it helps against the flickering).

[dgudim]

Normal: animates from a smaller black window to full window
Desktop: visual glitches
Dock: Same black flicker
Splash: Longer black flicker
Notification: Longer black flicker

opacity 0: no effect???
Workaround: no effect

I could reproduce this on an amd iGPU system, nvidia 2060 system and the intel system I am writing from. So it's weird that you can't see that

[dgudim]

Although, after further testing, this appears to be only correlated with the cpu speed
I also noticed I am getting those ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for n times! errors
https://github.com/kando-menu/kando/assets/34401005/f98dedae-b059-4d97-a956-99caad21ec22

[Schneegans]

I've just seen that the opacity does nothing on Linux. So much to this idea. I am currently running Kando on KDE in a virtual machine and even there I see no flickering...

Here are some more ideas what you could do for testing:

• Somebody mentioned that app.commandLine.appendSwitch('wm-window-animations-disabled'); could help. You could put this line here.
• Temporarily remove this line. If you now press the hotkey, a completely empty window will open. You can close it with the Esc key. Maybe the initial drawing is now faster and the flicker is gone?
• Have you worked with browser development tools before? If so, we could use them to profile the performance and check whether we see some extraordinarily long loading times.

[dgudim]

1. wm-window-animations-disabled didn't work
2. Temporarily remove this line still flickers
3. Have you worked with browser development tools before? Yes, a little bit

If I am not misreading
Editor: 180ms (Why is it loaded even when not opened? 🤔)
Styles: 150ms
Other stuff: 70ms

[dgudim]

Also, what happens here is beyound my understanding))

Nothing for 180ms and then getOrCreateInstance -> Tab

[Schneegans]

How did you take those measurements? Is this a profile of Kando's startup (before opening a menu)? Or is it the first time a menu is opened? I think we should focus rather on the cases where the menu is opened a second or a third time in the same session. The very first time could take a bit longer as some resource will be allocated then. But all subsequent menu-openings should be fast.

Here is how I looked at this on my end:

0001-2770.mp4

As you can see, the first frame after showing the menu takes a bit more time than the later frames but at most we dropped one frame here...

[Schneegans]

Btw, have you tried building a release version of Kando (npm run package and then run the kando executable in out/Kando-linux-x64)? Or did you experience the issue with a prebuild binary from GitHub as well?

[dgudim]

Yes, this also happens with github binaries.
Here is the updated profile

out.mp4

[Schneegans]

The menu-loading time scales about linearly with the amount of menu items. I looked at the DOM tree creation code and was able to significantly optimize it. Below are my timings of the show() method which you have seen in the callstack. I think you have been using the "Prototype Menu" which contains about 400 items.

	Before Optimization	After Optimization
Prototype Menu (~400 items)	50 ms	6 ms
Large Menu (~1450 items)	165 ms	31 ms
Crazy Menu (~16000 items)	1650 ms	350 ms

Even 400 items are pretty unrealistic in real-world applications, but this is a nice speedup anyways. I guess that it will improve the situation on your end as well!

However, even with these very long loading times, I did not observe any flickering! Maybe some other theme settings are interfering here? I was using KDE Neon from a Live-ISO in Virtualbox for testing. The timings above are from my real GNOME session, the timings in the VM were about twice as long in all cases.

If you want to, you could try the latest main branch and see if it makes any difference for you!

[dgudim]

Running off of the latest main is indeed a little faster. But there is still flickering. I even tried it on a new user, nothing changed. I am going to try the vm now

[dgudim]

Ok, can't reproduce in a vm (neon user/testing and arch gnome/kde) :(
The only reason I can think of is lack of proper gpu acceleration in a vm. Can I somehow disable hardware acceleration?

Edit: disabled, still there.... I give up, this is black magic, updating electron to 30 didn't help either

[Schneegans]

You could try to reproduce it with a minimal example. I just created this gist which you can simply import into Electron Fiddle. If you hit the Run-button, a transparent window will pop up. If this flickers as well, it's close to an electron bug...

[dgudim]

While doing some random stuff I noticed that kando is starting under xwayland, is that expected?

And the test does work, no flicker:

Screencast_20240516_203553.webm

[dgudim]

Setting ozone platform to wayland gets rid of the flicker, but the menu is also gone))

[Schneegans]

And the test does work, no flicker:

Could you also set frame: false, in the window's properties? I guess it will make no difference, but let's be on the safe side.

While doing some random stuff I noticed that kando is starting under xwayland, is that expected?

Yeah, that's Electron's default mode on Wayland. At least on GNOME it works okayishly with ELECTRON_OZONE_PLATFORM_HINT=wayland but there are some issues. Sometimes the window is not on top, for instance. But I haven't looked into this yet.

[dgudim]

Could you also set frame: false

Alredy tried, no flicker

ELECTRON_OZONE_PLATFORM_HINT=wayland

Yoooo, this WORKED
https://github.com/kando-menu/kando/assets/34401005/b07efbb0-cc41-490f-b70b-5735793ff184

I think this is indeed either an electron bug or electron on xwayland bug

[Schneegans]

Cool! But still weird that it does not happen in the VM. And I am aware of several other KDE users and they do not seem to have this issue either.

So let's close this issue for now? Maybe someone else shows up with the same issue and than we can reopen it and try to narrow down potential reasons...

[dgudim]

Yes, sounds good to me. Thanks for the quick help!