search

kando-menu / kando

🥧 The Cross-Platform Pie Menu.
https://ko-fi.com/post/Kando-1-0-0-released-G2G5Z1DOS
Other
1.18k stars 25 forks source link

Flashes black on start for a split second #423

Closed dgudim closed 1 month ago

dgudim commented 1 month ago

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 commented 1 month ago

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

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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:

dgudim commented 1 month ago
  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

image

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

dgudim commented 1 month ago

Also, what happens here is beyound my understanding)) image

Nothing for 180ms and then getOrCreateInstance -> Tab

Schneegans commented 1 month ago

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:

https://github.com/kando-menu/kando/assets/829942/00afd2c6-20c6-42e1-9ce0-23db52a011f8

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 commented 1 month ago

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 commented 1 month ago

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

https://github.com/kando-menu/kando/assets/34401005/4e7ae952-81bf-45c9-b132-c7af68624282

Schneegans commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

And the test does work, no flicker:

https://github.com/kando-menu/kando/assets/34401005/279b7cb4-f6e4-469b-b82b-e97c9ba5922c

dgudim commented 1 month ago

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

Schneegans commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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