Before we were inserting the id of the cover into the registry
from a rayon thread. But rayon will only execute N threads at the
same time and let the rest into a queue. This would casue mutliple
jobs being queued since the cover id was not inserted in the
registry until the downloading had started.
This fixes said behavior by having the main thread block and write
in the id in the registry.
Since loadign a pixbuf from the pre-rendered cache is the most
common operation and it does not affect the behavior we can
first check that and then if the cover is midway downloading.
This avoids a mutex lock for the most common path.
Accidently after f21398357b when a download would start,
it would lock the cover_dl_registry hashmap till it had finished.
Since the registry.read() happens on the main thread this would
cause the UI to block until the download was and the mutex guard
from the download thread dropped.
This adds a configuration option in meson, if set it changes the
application ID allowing for stable and development version to be
run at the same time.
I am not sure why, but cargo does not like it if flatpak-builder
and gnome Builder try to use the same target/ directory, even
though the environment should be almost identical.
The only difference is that Builder uses flatpak build instead of
flatpak-builder as far as I can see.
Jordan Petridis