[djh_]

I know jm said something about this before, to the effect of it not being possible, but I'm thinking it must be given that you can get so close with existing infolabels.

As you probably know, Aeon uses the filename and path infolabel to point to a copy of a movie's .tbn file. It does this because the available infolabel returns, at the very least, the entire filename complete with extension. How hard would it be to create an infolabel that simply stripped the extension and replaced it with .tbn?

[spiff]

why would you do such madness? the cache is there for a reason.

[djh_]

To display high-res thumbnails for specific uses like info pages.

[Freddo]

doesn't the largeimage control bypass the thumbnail cache?

[djh_]

Nope.

[Nuka1195]

i don't believe the large image control caches.

[jmarshall]

This won't be added for a very good reason:

We don't know where the thumb came from.

IMO you can just cache at the large size and just use largeimage controls everywhere you use a thumb. Who cares if your thumb takes a second or two to load? It's non-essential information, it doesn't have to be there immediately, and does not affect animation in anyway - after all, it will fade in nicely when it's done loading. Add mipmapping in to improve the quality of thumbs that are downsampled and we're done.

If we have to do multiple copies, then we can do so once the thumbcache gets it's rewrite. I personally would prefer looking into some of the compression techniques and just start caching single copies of large compressed textures with mipmapping for smaller versions.

Cheers,
Jonathan

[djh_]

Who cares if your thumb takes a second or two to load?

I get what you're saying, and I did use largeimage thumbs at one point. But given some of the things people have issues with, I guarantee you that just about everyone will mind them popping in one by one every time they use the scrollbar.

No problems, though - I'll just make do for now.

[jmarshall]

Does it really take that long? I haven't really tried it out to be honest. The idea in the future is that we'll keep textures around longer than they are currently (2 seconds) so that they'll be instantaneous if you scroll back (assuming your GPU memory isn't full

Really it's something you have to do when scrolling through large lists with lots of images - the loading of the images otherwise slows down the scrolling way too much.

Cheers,
Jonathan

[Jezz_X]

I think jmarshalls main response is sure it might work fine if we always assume that everyone uses a local thumb for every single Icon they have but the reality is lots of people even more so the non windows people rely on the downloaded ones. So we can't just assume it comes from a certain place and depending on their connection will take even longer to get another big one

[djh_]

Really it's something you have to do when scrolling through large lists with lots of images - the loading of the images otherwise slows down the scrolling way too much.

I can't argue with this as I tried it myself and suffered the consequences. But yes, I found that the large images degraded the browsing experience a bit too much. You skip a page and the thumbnails are empty; scroll too quickly and the thumbnails are empty; open a new window and the thumbnails are empty. Granted, they load soon enough, but put together every reload instance into a short space of time and you're looking at empty frames for half of it.

I personally liked your dual cache (one big, one small) suggestion the best, though I appreciate the overhead could be considerable.

[jmarshall]

Yeah - I don't care if they're empty while scrolling to be honest - trying to look at the thumbnail as it flies by is in my opinion not a particularly efficient method for finding something quickly - the first letter, or a text item is a much quicker way to identify where you are.

In either case, any type of "dual cache" won't be happening for 9.04 I'm afraid.

Cheers,
Jonathan