Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some preloading questions #1607

Closed
therobbot opened this issue Nov 23, 2016 · 3 comments
Closed

Some preloading questions #1607

therobbot opened this issue Nov 23, 2016 · 3 comments
Labels

Comments

@therobbot
Copy link

Hi,

first of all many thanks for your great work with this library.

I use Glide 3.7.0 in a hobby project to display album art in a music player app. I managed to add on-scroll preloading with the ListPreloader class that you provide and this works very well. However I still have some issues / questions:

  1. It seems that preloading only gets triggered once you really start scrolling. This means that if I start scrolling, the first items to become visible are not preloaded which is noticeable. I think this is because you use
    if (firstVisible > lastFirstVisible)
    in the onScroll callback instead of >=. Now I wonder if there's any way to work around this that I have overlooked. How can I have the first couple of invisible items preloaded when my GridView first becomes visible and the user hasn't scrolled yet?

  2. If I scroll quite fast, the preloader doesn't catch up anymore at some point which is not surprising. Now I'd wish for the following behavior:

  • When the GridView becomes visible, preload smaller resolution versions of all images in the GridView. Keep these in memory prioritized so they won't get kicked out by other images.
  • These images should then be used as thumbnails that are always available in the memory cache so at least they will be visible during fast scrolling. The rest of the memory is used for the preloading of the real images.
    Is a behavior like this possible to emulate using your library?

Thanks,

Tobias

@TWiStErRob
Copy link
Collaborator

TWiStErRob commented Nov 23, 2016

  1. Yes, I've noticed that too, but wasn't bothered enough to look deeper. You can copy/extend the ListPreloader class and try to improve it. Pull requests are always welcome.

  2. That's not a good idea, would you really want to fire 2000 requests when a user opens a long list? I mean if you really want, you can always use downloadOnly to pre-cache, but there's no general purpose solution for this as far as I know. Granted downloadOnly won't solve memory caching.

What I suggest is to use a placeholder, or some placeholders. Placeholder(s) satisfy the "at least they will be visible during fast scrolling" requirement pretty well and they're not as resource intensive as separate thumbnails.


If you want to go full-on with your behavior, you can achieve it by the following steps:

  • create SimpleTarget instances for each item
  • start a Glide load for each separately
  • add .override(w,h) to each of the above; and also the same override each time you want to use the pre-cached image in bind
  • add a transformation (.fitCenter()/.centerCrop()) and also the same each time you want to use the pre-cached image in bind

Size and transformation need to be the same for memory cache to hit! The SimpleTarget forces the resources to be "active". Active resources are in-use, they are checked before the memory cache is queried and cannot be evicted (= put back to memory cache) until all instances are cleared (automatically through lifecycle or manual Glide.clear)

@therobbot
Copy link
Author

Hi,

thanks for the reply. I now copied the ListPreloader class and managed to solve issue #1 even though I'm not 100% happy with my code. I set lastFirstVisible=-1 in the constructor. This means that during the first call to onScroll() the preload always happens. But I also have to check if the preload was successful (i.e. if the dimensions have already been set) and otherwise I don't update lastFirstVisible. It still feels kind of hackish but it works.

About #2: I'll take your advice and first try to use a placeholder. Since I only use local images that should already be cached in a resized version on disk, I wouldn't care so much about many requests, though. I might also try how this works at some point.

Thanks for pointing me in the right direction.

Tobias

@TWiStErRob
Copy link
Collaborator

Ah, yes, the size is not known in the beginning. It's tricky sometimes, but if you can encapsulate it nicely, there may be no better solution.

Tip: on GitHub never use #number unless you're referencing an issue; I use number) as an alternative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants