Re-re-re-thinking thumbnails

Ideas for improvements and requests for new features in XnView MP

Moderators: XnTriq, xnview

Post Reply
User avatar
JohnFredC
XnThusiast
Posts: 2010
Joined: Wed Mar 17, 2004 8:33 pm
Location: Sarasota Florida

Re-re-re-thinking thumbnails

Post by JohnFredC » Thu Jul 18, 2013 12:48 pm

MP 0.60 has a partially implemented improvement of thumbnail handling. Greatly appreciated, indeed, but it doesn't go far enough.

The following is extracted and re-edited from a post I made 3 years ago. IMO it remains completely relevant:
  • 1. Completely abandon both the current thumbs slider behavior and the thumbnail/image resizing paradigm, which is based on thumbs cartouche size and which causes MP to unnecessarily reread the original file over and over (and over and over) again.
    Instead: make the thumb slider specify how many columns and/or rows of thumbs to show in the thumbs panel.

    2. Save the number of columns and/or rows for each folder separately AND/OR...

    3. ...save the number of columns and/or rows for each browser layout. Currently (in MP 0.30 up to 0.60) and all other versions of XnView) the thumbnail cartouche size and browser layouts are disconnected from one another. IMO this is crazy.

    4. Allow the user to specify thumbnail image resolution separately from thumbnail cartouche size. 3 resolutions should be sufficient: "coarse", "medium", "fine", for instance.

    5. Initially default to "intelligent" values for the three resolutions based on screen dimensions at installation, but give the user the ability to change them/rebuild them/store them.

    6. Build and store the 3 resolutions (course, medium, fine) for each image file into the cache when the user initially enters each folder (or specifies rebuild thumbs), or when MP detects that an image file has changed, or when the user makes changes to the ini settings.

    An efficient way to do this would be to extract/build the "fine" thumbs image first and then rescale the other two resolutions from it. This avoids reading the image file more than once.

    7. Allow user to define thumbnail cartouche "info" layouts independently of thumbnail image resolution and for each of three cartouche sizes. For me, three thumbnail "info" layouts (no info, some info, lots of info) would be sufficient.

    A "small" thumb cartouche would display the "no info" layout, a "medium" size cartouche would display "some info" (perhaps just the filename), and a large cartouche the "lots of info" layout. The visibility of thumbnail icons/symbols should also be specifiable for each "info" layout.

    8. When the user moves the thumbnail size slider:
    • a) Change the number of rows and/or columns of thumbnails displayed in the panel.

      b) Change the thumbnail cartouche size to fit the rows and/or columns of thumbs exactly into the thumbs panel.

      c) Change to the thumb "info" layout (small, medium, or large) that best fits the newly calculated thumb cartouche size.

      d) Display the appropriate thumbnail image resolution from one of the three stored sizes ("coarse" for small thumbs, "medium" for medium thumbs, "fine" for large thumbs) without rereading the original image files!

      e) Finally, to make everything fit perfectly, adjust the thumbnail spacing to evenly fill either the width or height of the thumb panel (no wasted space) based on the aspect ratio of thumbnail panel width/height.
    8. When the user resizes the thumbnail panel...
    • a) Incrementally change the size of the thumbnails cartouche AND spacing to maintain the number of rows and/or columns panel previously set by the thumb slider. If necessary, automatically switch to the thumbnail info layout that best matches the new thumb size.
    9. Again: whenever MP must resize the thumbnail cartouches, resize the displayed thumbnail image from the currently displayed cached resolution! Do not rebuild the cached thumb from the original image itself without asking the user! (Already implemented)

    For instance, when resizing the thumbs panel (or moving the thumbs slider) causes the thumb cartouche size to select for the "some info" thumbs layout (but not yet large enough for the "lots of info" layout), rebuild the thumbnails image to fit the thumbs cartouche by resizing the assigned "medium" cached image, NOT by rereading the image file itself. Avoid re-reading the original file at all costs unless the user requests it.
SUMMARY

This is a complex approach to explain and I apologize for that, but it should make the thumbs situation much, much faster!
John

thibaud
Posts: 269
Joined: Sat Dec 02, 2006 12:41 am
Contact:

Re: Re-re-re-thinking thumbnails

Post by thibaud » Thu Jul 18, 2013 1:44 pm

I'm not sure having the thumbnail cell re-sized every time the browser window is re-sized will be much faster :)
I still believe this would look way better this empty space sitting at the end of each row is something that bothered me since xnview exist

I vote Yes for all points.

Post Reply