Images inside recyclerview flash when notifyDataSetChanged() is called
See original GitHub issueI’m migrating my code from Picasso to Coil and discovered a strange behaviour non present with Picasso.
A recycler view contains images but when I call notifyDataSetChanged()
on the adapter some images flash as shown in attached GIF
I created a project useful to reproduce the bug, CoilFlashing
Version Coil 0.9.4 Android 9 and 10 under Android emulator, Xiaomi MiA1, Pixel 3XL
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:5 (3 by maintainers)
Top Results From Across the Web
android - RecyclerView blinking after notifyDatasetChanged()
Without stable IDs, after notifyDataSetChanged() , ViewHolders usually assigned to not to same positions. That was the reason of blinking in my ...
Read more >How to Avoid That RecyclerView's Views are Blinking when ...
However, when we refreshed the RecyclerView by notifyDataSetChanged() , it is blinking for a short time, especially strange on cell's inner image view....
Read more >How to fix blinking issue for RecyclerView notify changes
NotifyDataSetChanged(), adapter.notifyItemChanged(int position) etc methods then your RecyclerView blink for few nanoseconds.
Read more >Android RecyclerView Gotchas |
RecyclerView's have a bad habit of “blinking” when they update. Basically, it happens when the view refreshes its images. They briefly disappear and ......
Read more >Slow rendering
Inside Systrace, you can click on RecyclerView-traced sections to see an ... make sure that you're not calling notifyDataSetChanged() ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@mattlogan I agree this behaviour isn’t best for UX in certain cases. Also after reviewing Picasso’s code, it looks like they do check the memory cache on the main thread. They’re also able to avoid waiting for the request’s size as their
Transformation
interface does not include asize
param (which limits what you can do with a transformation).Coil clears the drawable in
onClear
to support bitmap pooling and also to preemptively clear images attached to detached Fragments and detached views in a RecyclerView’s view pool. We could avoid callingonClear
if bitmap pooling is disabled, however we still clear the drawable inonStart
at the beginning of the next request.Unfortunately there are two competing use cases with Interceptor support and maximizing UI thread performance on one hand and synchronous memory cache checks on the other. That said, I think it’s worthwhile (and possible) to support both use cases with a boolean flag when constructing your image loader - something like
ImageLoader.Builder.allowSynchronousMemoryCacheChecks(true/false)
.allowSynchronousMemoryCacheChecks
would need to be disabled to add anInterceptor
. What do you think? I’m going to reopen this issue to track.Hey Colin - I understand your reasoning above for checking the cache asynchronously, but I noticed that Picasso doesn’t have this issue despite also checking the memory cache off the main thread. I’m not sure I understand why checking the memory cache asynchronously necessitates clearing & reloading the image as it appears to be doing now. Perhaps you could wait to clear the image until the memory cache check completes?
It would be awesome if you have an idea for another solution here, otherwise I think this will lead to a slightly degraded UX for situations like the one described above. Thanks for the awesome library!