View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013011 | MMW 5 | Track Browser | public | 2015-12-10 17:51 | 2022-09-14 14:32 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | feedback | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.2 | ||||
| Summary | 0013011: Views that browse images are jumpy, slow to scroll, and slow loading | ||||
| Description | Although there have been improvements in this area, when browsing views that contain many images (e.g. Albums view) there are still a couple of issues: 1) scrolling is jumpy. As the user scrolls, every couple of seconds the scrolling stops (it appears as if MM is trying to load images and in doing so blocks the user from scrolling). 2) scrolling takes too much time because on a standard laptop with 1366x768 resolution, only 10 albums/images display at once. It takes a lot of scrolling to get through a collection! It would be preferable to shrink the default image size so that more images (~15?) display on a single standard laptop screen. 3) Once the scrolling slows down / stops, artwork loads slowly--sometime over several seconds--and in an apparently random fashion. It would be much cleaner if the artwork loaded in the order displayed and more rapidly. A screencast illustrating points 1 and 3 is at: http://screencast.com/t/S6K718X0Z2z0 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2009 | ||||
|
|
I guess you had a DbgView window opened, right ? I see the same when the DbgView window is opened, but if I close it then scrolling is smooth. So it looks that we just need to eliminate too many debug messages when scrolling. |
|
|
Fixed in 2009, reduced the debug messages |
|
|
Might be the DbgView, but maybe it's that the machine really is that slow? Rusty please confirm. As for 2), I guess that it depends on personal preferences and possibly also the screen size. Maybe we could introduce more (2-3) versions of all image views (Albums, Artists, ...), possibly also with varying features, like grouping by first letter, text overlaying the artwork (instead of below it), etc. |
|
|
To replicate: 1 Delete the MM5 directory 2 Install MM5 3 Go to Music > Albums and scroll I retested 2037 and scrolling after images have been cached is fine. The problem is that prior to the images being cached, the images load left to right, line by line. e.g. for the following grid 1 2 3 4 5 6 7 8 9 The users sees the images load in numerical order. It would be preferable if MM5 would cache the images as a background process rather than waiting for the user to scroll through artwork and get a poor first-time experience. |
|
|
The images are cached in low priority background threads so it is strange that it is not smooth for you. For me it has been always very smooth (even with deleted /Portable/Temp/Thumbs/ ) The only case when it isn't smooth in my case is when the DbgView app is running. Not sure why, it has an impact on this. Is DbgView app running in your case too?? If not then I guess that the disc access (even in other threads/processes) has an impact on the Chromium rendering in your case. Do you have SSD disc or HDD? What are the further PC params? EDIT: Watching that Petr replaced JPEG library and the thumbs creation is now done via thumbGen.exe process (#13559). My guess is that it could be a regression? I remember that many calls of an EXE on your PC caused issues (the installer freeze issue recently). So I guess that calling thumbGen.exe for each thumb separately could cause the issues on your PC. To confirm: Could you try whether the issue happens with build 2034? |
|
|
My PC isn't that fast (0000561:0001900 on CPU benchmark) but with its SSD it's faster than many mainstream laptops today. The issue occurs in previous builds as well. To re-iterate, it's not a functional problem--MM5 image loading is reasonably fast. The problem is in how it appears to the user (not as smoothly as in Groove or MMA) in that they can see the images loading individually (prior to the images being cached). I would expect that the problem would go away completely if caching were done _prior_ to the user scrolling to the images for the first time. However, I also think that we shouldn't spend too much time on this since the problem isn't too bad, and is limited to the first scroll. |
|
|
ok, we could add it to the video thumbs generation thread that is auto-running after scan or 10 seconds after MM5 start |
|
|
Reviewing #13016 I have found out that MM5 Caching is still not fully matured and is something we should consider for v5.1 optimization where we would use more permanent Image/thumbs caching and cache control to users. ATM thumb and Auto Lookup search fill the gap where users gets its view filled with album art, but it can happen that album art is re cached making non needed double process. I would think to lower number of background threads and making caches more permanent and not so easily cleaned by system cleaners. |
