Skip to content

v0.99.5: Multi-core texture handling & time-to-album-grid reduction - #300

Merged
htkhiem merged 20 commits into
mainfrom
fix/remote-perf
Jun 10, 2026
Merged

htkhiem merged 20 commits into
mainfrom
fix/remote-perf

Conversation

@htkhiem

@htkhiem htkhiem commented May 31, 2026 •

Copy link
Copy Markdown
Owner

Refactors this PR brings:

Album & Artist Grid init speedup

TL;DR: if you run MPD on a remote server with a big library and have been waiting for >1min for the Album View to stop showing the giant spinner, you're in luck. I've sped it up to the point a 3,000-album test library takes ~3s to show up as the grid.

To display each album in the grid, we need to fetch its first track from MPD (to get things like albumartist, example URI for albumart, audio quality, etc). Previously Euphonica would send, per album, one find command that would resolve to all information about a single track, then one stickers command that would then fetch all of its stickers. For the above example, that meant 6,000 commands having to be sent and responded to.

This PR (and a new commit to my fork of rust-mpd) enabled multiple find commands to be executed in a command list. By batching 256 finds into one call, we massively reduced latency and improved network bandwidth utilisation at the same time.

Stickers, however, can't be batched that way (as not every album has a rating sticker, and querying the sticker for such an album would be an error and would halt the whole command list). I've instead deferred the stickers fetching, such that we'll now fetch the basic info first, display the grid, THEN fetch the stickers to fill in later.

The same optimisation has been applied to the Artist View too with similarly great uplifts.

Multi-core texture handling

Upon downloading an image, Euphonica must transcode it to RGB8 and perform 2 resizes to a hi-res version and a thumbnail version. On later reads from disk, each compressed file must also be decoded before going into VRAM. This is currently queued on a single CPU core. While this doesn't block the main UI thread, it causes other background tasks to backlog, so everything else takes more time to load.

This PR parallelises such operations using glib::ThreadPools. The threadpool size is configurable in the UI and defaults to 4, though if you have more CPU cores/threads it might be worth trying higher values.

This should somewhat speedup cold-start population of textures, as the population speed should now be solely bounded by your download speed and not single-core performance.

Note that external download operations, including from your MPD server, are still sequential to avoid clogging the server and/or getting banned.

Smarter visibility checks & LOD-like resolution progression

Viz check frequency has been reduced to every 50ms (~20fps), and all viz checks are now synchronised to a central clock.

When there is a >=10-task backlog in the background queue and if high-resolution album grid is enabled (by default), we'll fall back to thumbnails. Once said backlog is cleared, album cells currently visible on screen will then attempt to upgrade to high-resolution arts. Those once loaded at thumbnail resolution but no longer on screen (i.e. scrolled past) won't be upgraded. In other words, this reduces the number of high-resolution album arts having to be loaded with zero visual impact.

This enables textures to more quickly fill the album grid for already-downloaded cases.

@htkhiem htkhiem changed the title Replace per-frame viz check w/ 2Hz central loop v0.99.5: Multi-core texture handling & time-to-album-grid reduction Jun 6, 2026
@htkhiem htkhiem linked an issue Jun 7, 2026 that may be closed by this pull request
@htkhiem
htkhiem merged commit 0b78d7d into main Jun 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Doesn't display album art after it's already uploaded.

1 participant