View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002969 | MMW v4 | Main Panel/Toolbars/Menus | public | 2007-04-02 17:30 | 2007-04-11 10:23 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Summary | 0002969: Make Album art views less CPU intensive | ||||
| Description | We should consider some kind of disk caching of album art, so that switching to AA view would be faster. E.g. we could cache album art in kind of BMP format in Temp folder (resized) so that its reading would be considerably faster then. By words of [stefan.brueck at wolfsburg.de]: album pic caching is lousy as in Music Match. one could scroll or take the slider downwards and the result is that even after 1h playing with MM3 there's still albums with no covers cached. I wonder why MM3 isn't realising to use spare CPU time to cache them. You could use it for an hour, then switch to another view / differnt content, and you again see that it has to cache pics it didn't know yet. (AMD x64 dual core 2 Gig 2 1600x1200 TFTs) | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Assigning to Petr to think about it and discuss details with me over IM. |
|
|
The user further complains that the memory usage can get really high, probably because of storing all of the images in memory. Here are some thoughts about how should it work (I'm not sure about all current implementation details): 1. There should be a class that handles the caching. When it reads an image from the original source (tag or linked file with album art), it caches it in memory, once for every album, regardless of number of tracks of that album. 2. The image cached in memory isn't in the original dimensions, but in some predefined one (something like 80x80? - or rather 80xsomething, in order to maintain aspect ratio) so that large images don't take all the RAM. For the actual showing the image on screen, another resize operation might be needed, which can degrade its quality slightly, but it won't be anything significant. 3. These resized images (or rather thumbnails) should be stored in some temporary folder (MMAACache folder in Windows Temp folder?) in an uncompressed way, i.e. RGB triplets, making it 80x80x3 (+few bytes for a header) bytes large for each album. Albums should be probably indexed by names? 4. Just proper updating of album art stored on disk should be discussed, i.e. what to do if user: a. Changes album art, b. Changes album name, c. changes album artist. In these cases it would probably make sense to always update that cached uncompressed thumbnail in temporary folder. |
|
|
5. One more idea re. cached images storage: For performance reasons it would make sense to not store them all in single folder, but rather in several folders, something like F00, F01, ..., F19. This is an approach used e.g. by iPod or Internet Explorer for storage of cached content in order to ensure fast look ups. File would be distributed using a hashing function - something like defined in Structs.pas. |
|
|
fixed |
