Thanks for the feedback, all.
Going back to the old way is not in the cards, but we can definitely look at experience issues caused by these changes and work to improve image display performance where itâs currently lagging.
First, to be clear, the changes that we made here were not aimed at shrinking backups. Thatâs just a pleasant side effect.
In the old world, we downloaded artwork when importing your library, and then updated it on a regular basis (more or less, downloading it over again) to keep it up to date. This was problematic for a number of reasons.
During the initial import of a music library, a large portion of the time required to import the files was spent downloading artwork, and much of that artwork was viewed infrequently or not-at-all. It was a big waste of bandwidth, and a waste of our usersâ time making them wait for this when first using the product.
To keep artwork up to date, the Roon core used to update each image file every 7-14 days This means that at some point during the week, the Roon Core would wake up and startâŚwell, doing stuff. CPU usage happens, more network activity happens, fans may turn on. For people with large libraries, this background work could be running a lot of the time. This is something that many people have complained about, and something that we were becoming increasingly uncomfortable defending as reasonable behavior.
Another problem with the old scheme is that the Roon core had to guess about the artwork resolution too early, instead of being able to take into account what a given display device needs. We used to download images in two sizes, âsmallâ (roughly 256x256), and âlargeâ (roughly 1024x1024). This was fine 10 years ago when almost all screens were roughly 130dpi, but today we have âretinaâ displays, 27" 4k monitors, etc, and this one-size-fits-all approach was not working. Sending low-res images to high-density devices was making Roon look blurry or pixelated, and sending high-res images to low-density devices would in many cases cause it to perform badly.
So we needed to move to a system where display devices can request exactly what they need. For people with diverse display devices, that could require up to 6 pre-scaled copies of each image for different devices / display use cases. Downloading all 6 possible sizes that any device could ever ask for in advance is not an optionâit would increase the problematic resource usage that I described above threefold.
Finally, the 7-14 day update interval was pretty long, and shortening it, again, acts as a multiplier on the resource usage associated with artwork. Itâs especially offensive in an environment where we are asking users to contribute images to Art Director. In the new world, images should take less than 72hrs to flow through all of the various caches and become visible in-app.
The way Roon handles images today is essentially the same as how every other app that you use handles images. They are fetched on the fly at view-time and cached in various ways inside of the application to speed up future views. In the backend, we use a content distribution network to globally distribute the images and make sure that load times are fast for everyone. In most cases it works very well and the experience difference is minor. We can work to improve the other cases.
I think itâs better for everyone that we stop trying to manage huge pre-downloaded repositories of images on the Roon Core. These changes will make the whole product perform better, more efficiently, and more reliably by removing work and complexity, and will make images look better and load optimally on all devices.
