Provided artUri resolution must appear on android lockscreen

[rohansohonee]

Your implementation for optimising art bitmap has resulted in very low res artwork to appear on lockscreen. Can this optimization be reverted? Or should a flag be set, say optimise art bitmap true/false. What do you think??

FYI: I am supplying a PNG of 640x640 as my artUri. It is a standard artwork resolution.

I have noticed that you are scaling it down to 96x96 in android. Am I correct?

[ryanheise]

I agree something needs to be improved here. Exactly what should be done is difficult to answer.

The simplest option would be to provide an option to specify the degree of down-scaling.

But if you have a large number of media items in the queue at high resolution, you will run out of memory, so in that scenario we will still need an LRU cache to hold the bitmaps in memory.

I can implement the simpler option as both a first step and a short-term solution.

[rohansohonee]

@ryanheise Do you have knowledge on what techniques Google Play Music/Spotify use to overcome this?

Will try from my side also to implement a solution for this problem.

[ryanheise]

I don't know how we can find this out short of reverse engineering, but I think we don't need to go there. As a starting point, there's Google's advice:

https://developer.android.com/topic/performance/graphics

There's also discussions on StackOverflow:

https://stackoverflow.com/questions/18255572/android-bitmap-cache-takes-a-lot-of-memory

Reading those, it is wise to have both a disk and memory LRU cache.

It is also wise to preload artwork so it is ready to display by the time setMediaItem is called, but this is secondary and it can be done via application-level logic. i.e. The application knows which media item is likely to be shown next, and can ensure it is in at least the disk cache. If it's there, it can be loaded into memory quickly enough.

This is all in addition to an option to configure the downscaling resolution.

[rohansohonee]

How about using Glide/Picasso to resolve this problem?

https://github.com/bumptech/glide/wiki/Loading-and-Caching-on-Background-Threads

[ryanheise]

Perhaps, if there is a way to turn of its disk cache (since we want to use flutter_cache_manager for that).

But on the other hand, the only thing left to implement is the LRU memory cache which should be very easy to implement with: https://developer.android.com/reference/kotlin/android/util/LruCache

There's also the tradeoff of including the bloat of glide compared to writing 10 lines of code for the simplest approach.

[rohansohonee]

I will try to implement LRU Cache.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with audio_service.