deefrawley
commented
2 years ago The log should show the startup process and what is taking the longest. If you type open log in Flow it should show the result to open the log file location.
Open fabchelly opened 2 years ago
deefrawley
commented
2 years ago The log should show the startup process and what is taking the longest. If you type open log in Flow it should show the result to open the log file location.
jjw24
commented
2 years ago I think this might be the same issue with the discussion here https://github.com/Flow-Launcher/Flow.Launcher/discussions/586.
@fabchelly can you replicate this problem everytime flow starts? Can you attach the log here after it happened please.
fabchelly
commented
2 years ago Yes it happens everytime after start. I cleared the log and restarted the program. The problem seems to be related to the error displayed in the log (at line 630, Spotify?). 2022-05-15.txt
I tried to restart the app multiple times and I have found other errors appearing in the logs while the freeze happens: 2022-05-15-error2.txt
Every error seems to be related to application icons not found by the system.
taooceros
commented
2 years ago We are supposed to have a asynchronous access to icon so theoretically that shouldn't be an issue. However, probably it is stunt because of the buffer is not ready?
fabchelly
commented
2 years ago I have uninstalled SpotifyPremium and I don't have any error in the log anymore but the first search stills hangs for 2 seconds (after 1 character entered) before displaying the result.
I come back to my first idea: simulate a first search internally after start can be a way to circumvent any slowness provoked by a plugin the first time it is executed. Whatever happens while indexing will be treated before a first real query is made.
taooceros
commented
2 years ago It may be a reasonably workaround. Though a bit unclean for implementation. But I think it is a UI issue. So you still need to wait for the simulated query freezes for a while?
Anyway we can take a try. I will give it a test and send you an artifact later.
fabiochelly
commented
2 years ago Yes, nothing has change (on both of my computers). There are both very recent (i7 and i9 from this year) so I don't think it is related to a lack of CPU power.
It can be related to the graphics as both screens are 4K set to 300 dpi and there may be a latency to recalculate element on those definitions.
Whats happens precisely is that if I type "flow" after a restart for instance, only the "f" appears. Then, after a 2 to 5 seconds freeze, the rest of the word appears instantly with the response.
taooceros
commented
2 years ago yeah I understand your issue. We have seen that before, but I have no idea how to fix it since it is very likely a UI framework issue.
fabchelly
commented
2 years ago Anyway we can take a try. I will give it a test and send you an artifact later.
I'm ready to test the workaround as soon as it is ready. Thanks.
github-actions[bot]
commented
2 years ago This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
github-actions[bot]
commented
2 years ago This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.
The first query after Flow Launcher starts is always extremely slow (whatever I'm trying to search) like if some index is created at first search. It's probably triggered by one of the plugins using "*" as pattern (it hangs after the first character entered whatever the query is). After this first search every following request behaves normally.
In order to prevent this first slow-down, can a first search be simulated just after Flow Launcher starts? It should be easy to simulate a search at startup (with a random string of 1 or 2 chars) to trigger this slow indexing process (for any plugin that need it the first time).
Thanks, Fabio