Page MenuHome

File browser - change thumbnails size with a slider

Authored by Yaron Dames (DMS) on Apr 26 2015, 6:46 AM.



I've added a slider to change the thumbnails size interactively.
the slider is located on the "file browser" menu (the header), and it appears only when
we're on thumbnails display mode.
we can scale from 32px up to 256px.
the default is 96px - like it was before.
Icons (for folders or files without preview images) are not scaled up beyond their original size.

Diff Detail

rB Blender

Event Timeline

Yaron Dames (DMS) retitled this revision from to File browser - change thumbnails size with a slider .
Yaron Dames (DMS) updated this object.

Ignoring the code for now (which seems mostly okay), the main question for me is how the actual resizing should be done... should we simply resize the generated thumbnail as done in this patch, or should we re-generate the thumbnail with the new size. The later one would bring much better results, but will be much slower as well.
We could also do this in two passes, the first pass would just deliver quick results by simply resizing, the second pass would re-generate the thumbnails with the new size. I think this progressive approach would be best UI-wise (without sounding too hard to implement).

Would like to hear @Bastien Montagne (mont29)'s voice before we do any more work on this.

@Julian Eisel (Severin),
thank you for your comment.
the double pass is a good idea. i'll wait for mont29 opinion. the current setup works for me, since i work on a very large screen but from afar, so i just need a bigger preview. the finer details are less important.

i would also like to implement a default size value in the user preferences, but I don't know if it's a good idea to clutter the user preferences screen with such a minor detail. again, i'll wait for your and mont29's opinions.

Eeeeeh… I would rather not have much changes done in filebrowser area currently, work done in assets-experiments rewrite it heavily. In the other hand, this patch is very simple and limited, so it should be easy to merge.

Some notes:

  • About size: current code in master is a mess, with some literal values in some places, odd defines (like that 96px) in others… D1255, which comes partially from asset-experiments work, aims among other things at unifying and cleaning this up a bit.
  • Also, our thumbnail manager is able to generate 256px previews, it's not used currently, but imho would be the simplest solution - pretty sure generating 256px previews is not that much slower than 128 ones, and you just have to scale them down if needed. I would not go to the two-steps approach for at least two reasons: code is/will be already enough complicated here (have a look at asset-experiments branch to understand what I mean), and that would mean having thumbnails in tow sizes on disk, yuck!

Btw, here on linux/gnome, OS's filebrowser is already generating 256px thumbnails it seems.

Yaron Dames (DMS) updated this revision to Diff 4096.EditedApr 28 2015, 7:44 AM

following suggestions from @Bastien Montagne (mont29) and @Julian Eisel (Severin):

  1. Thumbnails are now created at 256 resolution and only scaled down from the UI.
  1. .blend files preview images are also created now at 256 resolution.
  1. existing preview images are checked for size, if they are smaller than 256, they are deleted and replaced.
  1. added a function to give the numerical value of the Enum "ThumbSize" so we can get the value from different functions ("thumb_create_ex" and "IMB_thumb_manage")

some issues i ran into:

  1. there's a separate constant for the .blend files preview size (BLEN_THUMB_SIZE) and i don't see a good reason for that. I say let's unite them all... ;)
  1. the previews were originally generated in 2 * BLEN_THUMB_SIZE (2 * 128), and then scaled down to BLEN_THUMB_SIZE (for better quality i suppose). since i changed BLEN_THUMB_SIZE to 256, the previews are now generated at 512 and scaled down to 256. it still gives better image quality but i don't know if it's necessary now.
  1. THB_LARGE (from the ThumbSize Enum) is never used. the dir for this size (.thumbnails\large) is not even created. i did not want to delete it since I don't know why it's there in the first place.

I'll appreciate any comment from anyone.

Bastien Montagne (mont29) requested changes to this revision.Apr 28 2015, 11:54 AM

Answered about THB_NORMAL/LARGE in comments below.

Regarding BLEN_THUMB_SIZE, yes, all this could be harmonized… However, I would rather not do that in this patch, because I already worked on it in other branch(es) and would rather avoid too much merge headache. In fact, I would not touch to that value for now. Reason is, blend thumb is stored inside .blend files, which means that larger thumb may:

  • increase size (not much, but still, we switch from 64Kb to 256Kb, or so…).
  • break compatibility (not sure about that, need to check carefully the code, I would not expect problems with main blender, but we also have thumbnail generator script used to give OS .blend thumbnails…).
43 ↗(On Diff #4096)

Would keep this to 128 for now...


We could switch that to 128 imho, does not hurt on modern screens.


This func is not needed imho… But even if we want it, you should:

  • return directly value from each case item, avoids needs of explicit break line and tsize var.
  • Do not change sizes of THB_NORMAL/THB_LARGE! Those are common conventions (at least in unix/freedesktop world). Just use THB_LARGE to generate your thumbnails, instead of THB_NORMAL.

This is not needed, thumbnails are temp data by definitions, OS regularily cleans them out anyway.

This revision now requires changes to proceed.Apr 28 2015, 11:54 AM
Yaron Dames (DMS) updated this revision to Diff 4108.EditedApr 29 2015, 2:13 AM
Yaron Dames (DMS) edited edge metadata.

ignore this diff

Yaron Dames (DMS) updated this revision to Diff 4109.EditedApr 29 2015, 3:11 AM
Yaron Dames (DMS) edited edge metadata.

@Bastien Montagne (mont29)
thanks for all the suggestions. hopefully, I followed them correctly:

  1. reverted the BLEN_THUMB_SIZE to 128
  2. UI thumbs size is initialized to 128 (default) instead of 96.
  3. reverted the THB_NORMAL and THB_LARGE to old values (and "polished" the function). thumbs are created with THB_LARGE now.
  4. "get_thumb_dir" returns "/normal" dir for THB_NORMAL and THB_LARGE, so we won't be left with a leftover useless dir from previous versions.
  5. I left the date checking and size checking untouched because I saw no indication that the OS (in my case Windows7) deletes temp files (I have over 1800 files in the ".thumbnails\normal" folder). if I'm wrong, I will change it further. as for the size checking, I think we should leave it be, so new version instance will create new 256 thumbs and won't use the old 128 thumbs.

I'm sorry if I'm messing up your D1255 work. please notify me of any changes needed. I will abide happily.

Again, we do not want to change anything to thumbs dir or so, we are following a well defined standard here (

Further more, keeping things as is ensures us we'll use 'new' large dir, which means we do not need the ugly to check existing thumbs' sizes (in 'normal' dir we shall only have 128×128, and in 'large' dir, 256×256, so we just have to use 'large' dir and everything is OK).

Will finalize last edits and commit patch anyway, thanks for tackling this long standing TODO! :)

This revision was automatically updated to reflect the committed changes.

great! thanks for everything mont29.