MP 0.31 Win: Lazy Loading problems

[JohnFredC]

I wish there was a third thumbnail display mode somewhere between "Create thumbs for whole folder" = OFF and "Create thumbs for whole folder"=ON.

The problem with "Create thumbs for whole folder"=ON is that many times it simply takes too long to create thumbs in an uncached folder. MP just sits there making thumbs from the top down, and scrolling down through the thumb panel doesn't restart the thumbs creation at the new scroll position. The folder is essentially useless until it has been completely "thumbed".

The problem with "Create thumbs for whole folder"=OFF is that it doesn't always work.

With that setting, most (but not all) of the time when the user scrolls down in the thumb panel, thumbs creation resumes at the new place. I think that is the intended behavior.

But using the filter or performing a file action that changes the population of files in the folder can halt the thumbing activity and MP may just sit there doing nothing. This is particularly a problem when there are too few thumbs to fill the thumb panel. One frequently has to navigate OUT of the folder and then return to reset/restart the thumbing activity.

IMO it really makes no sense for the toggle "Create thumbs for whole folder" = OFF and "Create thumbs for whole folder"=ON to apply equally to cached thumbs as well as uncached thumbs.


Here would be a good behavior for my use:

• - Always display cached thumbs for the currently visible set of files/folders FIRST.
  
  - THEN, display all cached thumbs in the entire folder
  
  - THEN, create thumbs for all images in the folder before thumbing the sub-folders (a user toggle for this behavior would be welcome).
  
  - When thumbing image files, create the thumbs in file size order (regardless of the current sort order), small files first, then large files. This should fill the thumb panel to a more usable degree than currently (where the thumbs are apparently created in the current sort order).

Combining this approach with ideas from my other post here should make MP much more fluid and less frustrating to use.

One final thing: thumbnail creation performance should be tested on the slowest drive a user would reasonably be expected to employ. Perhaps an USB 1.1 thumb drive would be a good place to test. I don't use such a thing anymore, but if the thumbing process was optimized for a slow disk environment, it would "fly" in the more common faster ones.

[Troken]

Very intresting ideas, sounds well-reasoned.

[Troken]

JohnFredC, if I may extend your idea, wouldn't it be an idea to add two steps (no. 2 & 4)?

1. Display cached thumbs for the currently visible set of files/folders.
2. Display embedded thumbs for the currently visible set of files/folders (only for files that do not have cached thumbs yet).
3. Display all cached thumbs in the entire folder
4. Display all embedded thumbs in the entire folder (only for files that do not have cached thumbs yet).
5. Create thumbs for all images in the folder before thumbing the sub-folders (a user toggle for this behavior would be welcome).

[JohnFredC]

2Troken

• 1. Display cached thumbs for the currently visible set of files/folders.
  2. Display embedded thumbs for the currently visible set of files/folders (only for files that do not have cached thumbs yet).
  3. Display all cached thumbs in the entire folder
  4. Display all embedded thumbs in the entire folder (only for files that do not have cached thumbs yet).
  5. Create thumbs for all images in the folder before thumbing the sub-folders (a user toggle for this behavior would be welcome).

Thanks for your response! Honestly, I forgot about embedded thumbs (most of the problems I have with the thumbs behavior is with huge PNGs, of which I seem to have more and more these days).

So your additions to the thumbs display sequence make perfect sense to me. Besides, your list is more succinct than mine!

I might change #5 to read:

• 5. Create thumbs for remaining images (from smallest to largest) in the folder before thumbing the sub-folders (a user toggle for this behavior would be welcome).

To follow such a detailed plan XnView would have to hesitate for short period in order to assess and build the ordered thumb display list. For some folders /views, this "planning" overhead might require more time than the "plan" would save. Also, user behavior immediately after entering the folder would be a determining factor.

But countering this argument, perhaps MP could employ "most of the time" thresholds (set either explicitly by the user or by MP itself via an occasional automatic hardware performance assessment) that would cause MP to behave differently for different circumstances.

For instance, the thumb display strategy might vary if there were many very small images in the folder vs. many very large images, etc.

This all needs much refinement, though.

I wonder what statistics MP gathers about a folder before it starts the thumbing activity.

One final thing: Once a thumbnail has been displayed, don't remove it!!! I notice that with MP 0.31, scrolling quickly through a thumb panel can cause previously displayed thumbs to disappear.

[JohnFredC]

Here is another thing.

Suppose the user enters a folder with many subfolders that have not been thumbed. Then the user immediately enters one of those subfolders (before the thumbing for the parent folder has completed) and spends enough time in the subfolder for it to thumb completely.

Upon returning to the parent folder, the user will notice that the thumb for the recently visited subfolder is still blank, even though its contents have already been fully thumbed!

IMO MP should make efficient use of the thumbs it already has!

If a user enters a subfolder and resides there long enough for its images to become fully thumbed, then MP should automatically build/store the "4x" thumbs image for the subfolder's thumb in the parent folder without waiting for the user to return to it.

If this happens while the user is still in the subfolder, then when the user returns to the parent folder, the 4x thumbs image for the subfolder would be already cached, would not have to be redundantly thumbed, and could be displayed immediately.

[vommie]

One final thing: Once a thumbnail has been displayed, don't remove it!!! I notice that with MP 0.31, scrolling quickly through a thumb panel can cause previously displayed thumbs to disappear.

An exception should be the situation XnViewMP is using a critical amount of system memory, to prevent crashes.

I agree for the other points. Thumbnail creation and displaying is for me the most important thing of XnView. The option at moment is a nice step, but it would be even nicer go further.

At moment XnView handles "Create thumbs for whole folder" as the same as "Display thumbs only at slider position". This is confusing, because it's two different things. So it should be splittet into two.

For me the most important thing would be to precache some thumbs if (the hypothetic) "Display thumbs only at slider position" option is selected, so the users can scroll up and down a litle without having to wait the thumbs get displayed.

I also agree with the idea to start creating thumbs at the slider position instead strictly from the top of the sorting view. It should create thumbs only for the whole folder beginning at the slider position if both, "Display thumbs only at slider position" and "Create thumbs for whole folder" are selected. If only "Display..." is selected, but "Create..." not, XnViewMP should only create thumbs at/around the slider position, not for the rest of the folder.

But if there is a way to prevent crashes of XnViewMP caused by the 3GB-limit, XnView should create thumbs for the whole folder starting at the slider position in every case. I don't know if ACDSee is a forbidden word in this forum (:D), but it has the ability to load thousands of (big!) thumbs to the memory without getting above ~1GB. I'm no programmer, but possibly there are ways to improve the memory usage of XnViewMP too, so it does not care anymore how many files/thumbs are getting loaded