I can solve point 4 by allowing some option on a load that lets you determine whether or not an animation fires when an image is loaded from the memory cache. If it completes asynchronously, set the image on the View and animate.ġ, 2, and 4 all prevent a simple cross fade from one loaded image to another.If it completes synchronously (from the memory cache) set the image on the View and do not animate.Cancel any in progress load for the View and/or clear out any current image and recycle its resourc.Here's the basic lifecycle of a Glide request. Thanks for the write up, it's definitely a bit of a corner case. The side affect of that choice is that you may get an onResourceReady call in your RequestListener or Target with a resource your Target is already displaying. Rather than restrict the api to only allowing options we knew could be compared, the 3.x version of Glide simply relies on existing images to be in cache, but otherwise treats every new load equally, even if the new load is for an image that is already being displayed. Comparing all of the options requires each option to implement equals and hashcode which we can't guarantee for all argument types (Drawables for example). ![]() The 2.x version of Glide made an attempt to avoid restarting requests like this when we knew we were loading the same image, but doing so requires not only that the image you're requesting is identical to the one already present, but also that all of the options you used to construct the load (placeholders, transformations, etc) are identical those used previously. If you're showing an image in a view and you then attempt to load the same image into the same view, the only reason you don't see the image disappear and re-appear is that we get a cache hit so the second load completes synchronously. The behavior you describe is, at least currently, expected. but i just wanted to make it aware there seems to be a potential race condition (or just something setting the target's resource before this listener is called Anyway i did find a workaround that i can use. I tried to trace through the code to find out how this was happening but had no luck. When it was loaded from disk it behaved like expected Now keep in mind this only happened when the resource was loaded from the memory cache. but the majority of the time, the drawable in the target was already set to the resource being passed into the method. I ran it a bunch more times in the debugger and sometimes the references would be different. The drawables were the same according to the memory reference location. I put a breakpoint right after "current" was set and compared it to "resource". visually it would appear that the same image would crossfade into itself. TransitionDrawable transitionDrawable = new TransitionDrawable( new Drawable) ImageViewTarget image_target = ImageViewTarget) target ĭrawable current = image_target. Override public boolean onResourceReady( GlideDrawable resource, AlbumArtWrapper model, Target target, boolean isFromMemor圜ache, boolean isFirstResource)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |