Add daemon mode #95

loserMcloser commented 2022年01月24日 21:37:44 +01:00

Love fuzzel but it's slow to appear on my machines.

In comparison, love how fast foot appears when using server/client mode.

Love fuzzel but it's slow to appear on my machines. In comparison, love how fast foot appears when using server/client mode.

dnkl commented 2022年01月25日 07:01:53 +01:00

Have you tried latest master? It's not server/client, but much much faster from start-to-typing.

Have you tried latest master? It's not server/client, but much much faster from start-to-typing.

loserMcloser commented 2022年01月25日 16:43:06 +01:00

OK, tried a build from latest master:

• old laptop --- fuzzel window appears almost instantly, but icons take at least a second longer to appear

• newer desktop --- fuzzel window still sometimes delayed in appearing, but only slight delay in icons appearing

On my desktop /home is mounted over NFS as /home is shared by several machines in the house, so the extra delay there might be while fuzzel is searching XDG_DATA_HOME. (Though the network is gigabit and on the file server /home is exported from an SSD.)

OK, tried a build from latest master: * old laptop --- fuzzel window appears almost instantly, but icons take at least a second longer to appear * newer desktop --- fuzzel window still sometimes delayed in appearing, but only slight delay in icons appearing On my desktop /home is mounted over NFS as /home is shared by several machines in the house, so the extra delay there might be while fuzzel is searching XDG_DATA_HOME. (Though the network is gigabit and on the file server /home is exported from an SSD.)

dnkl commented 2022年01月25日 20:25:37 +01:00

old laptop --- fuzzel window appears almost instantly, but icons take at least a second longer to appear

Icons is what slows down startup the most. Especially SVGs. A "workaround" is to build fuzzel without SVG support (only PNG support). But note that many icon themes are SVG only... And yeah, not really a solution...

newer desktop --- fuzzel window still sometimes delayed in appearing, but only slight delay in icons appearing

I think you're right; the network mounts are probably what's causing the slowdown.

Having a server/client mode is an interresting idea, but as it would both mean more code to maintain, and also have limitations, like the application list not being updated when .desktop files are added/removed/updated, I think it's something that is out of scope for fuzzel.

> old laptop --- fuzzel window appears almost instantly, but icons take at least a second longer to appear Icons _is_ what slows down startup the most. Especially SVGs. A "workaround" is to build fuzzel without SVG support (only PNG support). But note that many icon themes are SVG only... And yeah, not really a solution... > newer desktop --- fuzzel window still sometimes delayed in appearing, but only slight delay in icons appearing I think you're right; the network mounts are probably what's causing the slowdown. Having a server/client mode is an interresting idea, but as it would both mean more code to maintain, and also have limitations, like the application list not being updated when `.desktop` files are added/removed/updated, I think it's something that is out of scope for fuzzel.

loserMcloser commented 2022年01月27日 03:30:57 +01:00

Icons is what slows down startup the most. Especially SVGs. A "workaround" is to build fuzzel without SVG support (only PNG support). But note that many icon themes are SVG only... And yeah, not really a solution...

So there's a delay to display icons on startup, but then when I start typing and new search results pop up that weren't in my fuzzel cache, the icons for those new items are displayed instantly.

Does fuzzel search for and load all icons from all .desktop files on startup? If so, is it because loading icons on demand causes too much of a delay in displaying search results? I think the trade-off should be in favour of faster start-up since probably most people are running cached items anyway.

Having a server/client mode is an interresting idea, but as it would both mean more code to maintain, and also have limitations, like the application list not being updated when .desktop files are added/removed/updated, I think it's something that is out of scope for fuzzel.

OK, that's fair. Maybe I'll play around with the idea on a fork sometime.

> Icons _is_ what slows down startup the most. Especially SVGs. A "workaround" is to build fuzzel without SVG support (only PNG support). But note that many icon themes are SVG only... And yeah, not really a solution... So there's a delay to display icons on startup, but then when I start typing and new search results pop up that weren't in my fuzzel cache, the icons for those new items are displayed instantly. Does fuzzel search for and load all icons from all .desktop files on startup? If so, is it because loading icons on demand causes too much of a delay in displaying search results? I think the trade-off should be in favour of faster start-up since probably most people are running cached items anyway. > Having a server/client mode is an interresting idea, but as it would both mean more code to maintain, and also have limitations, like the application list not being updated when `.desktop` files are added/removed/updated, I think it's something that is out of scope for fuzzel. OK, that's fair. Maybe I'll play around with the idea on a fork sometime.

dnkl commented 2022年01月27日 09:38:27 +01:00

In the last release, both the entire application list and all icons are loaded (but not rendered) before the fuzzel window is displayed.

In current master, the application list and the icons are loaded in a separate thread. The window is re-freshed twice; once when the application list has been loaded, and then again when the icons have finished loading.

None of this involves rendering the icons; this is done on demand when an icon needs to be displayed. Note that PNGs that needs to be resized caches the resized image, while SVG are re-rasterized every time. This is something we can tweak in the future, but shouldn't affect startup time.

So, while we do load all icons before displaying them, current master allows you to start typing much sooner than before.

In other words, fuzzel has moved from a very simple design, to a slightly more complex one, to improve time-to-typing at startup.

The next logical step is updating the window as soon as the currently visible entries have had their icons loaded, instead of waiting for all icons to load. We're not there yet, but I hope we'll be able to get there soon.

In the last **release**, both the entire application list and all icons are loaded (but not rendered) before the fuzzel window is displayed. In current master, the application list and the icons are loaded in a separate thread. The window is re-freshed twice; once when the application list has been loaded, and then again when the icons have finished loading. None of this involves rendering the icons; this is done on demand when an icon needs to be displayed. Note that PNGs that needs to be resized caches the resized image, while SVG are re-rasterized every time. This is something we can tweak in the future, but shouldn't affect startup time. So, while we do load all icons before displaying them, current master allows you to start typing much sooner than before. In other words, fuzzel has moved from a very simple design, to a slightly more complex one, to improve time-to-typing at startup. The next logical step is updating the window as soon as the currently visible entries have had their icons loaded, instead of waiting for all icons to load. We're not there yet, but I hope we'll be able to get there soon.

loserMcloser commented 2022年01月27日 17:24:26 +01:00

Hmmm, I guess maybe it might be nice to have some mechanism for the main loop to send a signal to the thread "hey we need these particular icons now so we can render them" instead of waiting until all icons are loaded for that second refresh.

Like maybe there is a shared queue between the main thread and the icon-loading thread.

• After a matches_update call, if EVENT_ICONS_LOADED hasn't fired yet, main thread pushes apps that need priority icon-loading onto the back of the queue.
• The loop in icon_reload_application_icons checks the queue on every pass. If the queue is empty or is locked, just load the icon for the next app in the application_list as usual. If the queue is not locked and not empty, lock the queue, load the icon for the app at the front of the queue, pop that app off the queue, then unlock the queue.
• Main thread notices that front of queue has changed, refreshes window so icon gets rendered.

Or something like that.

Hmmm, I guess maybe it might be nice to have some mechanism for the main loop to send a signal to the thread "hey we need these particular icons now so we can render them" instead of waiting until *all* icons are loaded for that second refresh. Like maybe there is a shared queue between the main thread and the icon-loading thread. * After a `matches_update` call, if `EVENT_ICONS_LOADED` hasn't fired yet, main thread pushes apps that need priority icon-loading onto the back of the queue. * The loop in `icon_reload_application_icons` checks the queue on every pass. If the queue is empty or is locked, just load the icon for the next app in the `application_list` as usual. If the queue is not locked and not empty, lock the queue, load the icon for the app at the front of the queue, pop that app off the queue, then unlock the queue. * Main thread notices that front of queue has changed, refreshes window so icon gets rendered. Or something like that.

tinywrkb commented 2022年02月08日 12:53:07 +01:00

The next logical step is updating the window as soon as the currently visible entries have had their icons loaded, instead of waiting for all icons to load.

I thought about creating a new ticket for lazy-loading images, but I'm now not sure if this is enough. The application would still race with a fast typing user.
Maybe lazy-loading + predication based on number of previous hits/exec.

Let me share a bit from my own experience.

On my system, I have over 250 desktop applications entries. A handful of them are host applications (fnott, foot, fuzzel, yambar, cups and cockpit), and the rest are Flatpak apps.
A large number of these apps I package and maintain myself, (mostly not on Flathub), so I have them installed even if I don't use them on a regular basis.
Others, I have interest in, so having them installed helps keeping track of them, and I will send PRs to the Flathub packaging when it need to be updated (outdated runtime, issues, and etc).
So I have too many apps installed, but there's a justification for that.

Storage space cost is not too bad as I have zstd subvolume compression enabled (~50% ratio). Flatpak having stable runtimes, and supporting delta updates, means this does not affect regular maintenance, there aren't many updates, and the changes are very small.

The only downside of having a large amount of apps installed is Fuzzel's startup time.

With Fuzzel 1.7.0, the application loads fast enough, but it takes about a whole second for the icons to appear.

Can we do better?

> The next logical step is updating the window as soon as the currently visible entries have had their icons loaded, instead of waiting for all icons to load. I thought about creating a new ticket for lazy-loading images, but I'm now not sure if this is enough. The application would still race with a fast typing user. Maybe lazy-loading + predication based on number of previous hits/exec. Let me share a bit from my own experience. On my system, I have over 250 desktop applications entries. A handful of them are host applications (fnott, foot, fuzzel, yambar, cups and cockpit), and the rest are Flatpak apps. A large number of these apps I package and maintain myself, (mostly not on Flathub), so I have them installed even if I don't use them on a regular basis. Others, I have interest in, so having them installed helps keeping track of them, and I will send PRs to the Flathub packaging when it need to be updated (outdated runtime, issues, and etc). So I have too many apps installed, but there's a justification for that. Storage space cost is not too bad as I have zstd subvolume compression enabled (~50% ratio). Flatpak having stable runtimes, and supporting delta updates, means this does not affect regular maintenance, there aren't many updates, and the changes are very small. The only downside of having a large amount of apps installed is Fuzzel's startup time. With Fuzzel 1.7.0, the application loads fast enough, but it takes about a whole second for the icons to appear. Can we do better?

dnkl commented 2022年02月08日 18:51:28 +01:00

I believe priority based on-demand loading will get us quite far. The application list is already sorted with the previous exec's at the top. This means they'd end up at the top of the icons-to-load list as well.

As the user types, we can just push the now-visible applications to the top of the icons-to-load-list.

I believe priority based on-demand loading will get us quite far. The application list is already sorted with the previous exec's at the top. This means they'd end up at the top of the icons-to-load list as well. As the user types, we can just push the now-visible applications to the top of the icons-to-load-list.

loserMcloser commented 2022年02月18日 21:18:51 +01:00

I have been using the new multi-threaded fuzzel version for a while now, and to be honest I think it is a step backwards in terms of usability.

Old behaviour: I wait for the window to show up, but when it does show up it is ready to go with my cached entries and all icons already displayed.

New behaviour: Blank window shows up, and then after a delay the cached entries show up, and then after another delay the icons show up. I can start typing right away when the blank window appears, but I still have to wait for search results to appear.

In the second case, if I start typing before the cached items appear, and the window remains blank, I now have to wonder: is the window blank because my search terms yielded no results, or because Fuzzel has not finished fully loading?

So in both design options I have to wait some time until Fuzzel is actually usable, and the new design just adds uncertainty/confusion and graphical incompleteness into that wait.

I will go back to my original suggestion, that Fuzzel could have a daemon mode, with desktop files and icons pre-loaded at session start. Then popping up a Fuzzel window should be nearly instantaneous. This is how ulauncher works, for example.

(Probably server/client was not the correct paradigm, I will change the issue title to reflect this.)

The issue of "desktop files could change" could easily be solved with a keyboard shortcut --- maybe Ctrl-R on a displayed Fuzzel window causes Fuzzel to "refresh" its desktop file store.

I have been using the new multi-threaded fuzzel version for a while now, and to be honest I think it is a step backwards in terms of usability. Old behaviour: I wait for the window to show up, but when it does show up it is ready to go with my cached entries and all icons already displayed. New behaviour: Blank window shows up, and then after a delay the cached entries show up, and then after another delay the icons show up. I can start typing right away when the blank window appears, but I still have to wait for search results to appear. In the second case, if I start typing before the cached items appear, and the window remains blank, I now have to wonder: is the window blank because my search terms yielded no results, or because Fuzzel has not finished fully loading? So in both design options I have to wait some time until Fuzzel is actually usable, and the new design just adds uncertainty/confusion and graphical incompleteness into that wait. I will go back to my original suggestion, that Fuzzel could have a daemon mode, with desktop files and icons pre-loaded at session start. Then popping up a Fuzzel window should be nearly instantaneous. This is how ulauncher works, for example. (Probably server/client was not the correct paradigm, I will change the issue title to reflect this.) The issue of "desktop files could change" could easily be solved with a keyboard shortcut --- maybe Ctrl-R on a displayed Fuzzel window causes Fuzzel to "refresh" its desktop file store.

dnkl commented 2022年02月23日 19:21:35 +01:00

We can add an option to disable the "new" behavior, and revert back to the old ways. But I'm trying to keep fuzzel simple, and a daemon mode is taking things a bit too far.

We can add an option to disable the "new" behavior, and revert back to the old ways. But I'm trying to keep fuzzel simple, and a daemon mode is taking things a bit too far.

WhyNotHugo commented 2022年04月13日 00:14:23 +02:00

Rather than wait for all icons to load, how about rendering as they're loaded, and damage-tracking just that region?

Would a script that pre-resizes icons into PNGs of the right size help? That would avoid rhe SVG rendering on each startup.

Rather than wait for all icons to load, how about rendering as they're loaded, and damage-tracking just that region? Would a script that pre-resizes icons into PNGs of the right size help? That would avoid rhe SVG rendering on each startup.

loserMcloser commented 2022年04月13日 18:01:50 +02:00

Closing because I've moved on to a different launcher.

Thanks!

Closing because I've moved on to a different launcher. Thanks!

dnkl commented 2022年04月14日 10:21:01 +02:00

@WhyNotHugo rendering icons as they're loaded is what was discussed earlier. I haven't abandoned that idea, but for it to really work, we can't just randomly load the icons - we need to load the ones visible first.

A PNG (or bitmap even) cache could work as well. My issue with that is that it is likely to keep growing.

In any case, I think this belongs in a separate issue.

@WhyNotHugo rendering icons as they're loaded is what was discussed earlier. I haven't abandoned that idea, but for it to really work, we can't just randomly load the icons - we need to load the ones visible first. A PNG (or bitmap even) cache could work as well. My issue with that is that it is likely to keep growing. In any case, I think this belongs in a separate issue.

dnkl commented 2022年04月14日 10:26:59 +02:00

#124

https://codeberg.org/dnkl/fuzzel/issues/124