Change thumbnail size in thumbnail view

[Matthias030]

I got inspired by this thread: http://www.ghisler.ch/board/viewtopic.php?t=25148

Many users look for a simple solution to change thumbnail size in thumbnail view. My suggestion is to cycle between 5 thumbnail sizes by pressing STRG+Mousewheel UP/DOWN or any other shortcut key.

[MVV]

Why only 5?

[Matthias030]

I hope that a smaller amount of sizes is easier to implement. So we have more chances to see this feature in next time. Of course, the premium feature is continuous size adjustment

Anyway for me 5 sizes are enough.

[sqa_wizard]

Well, please take in account, that thumbnails are not coming with the file, but have to be created for each file separately !

Each file has to be loaded into memory and processed by the according graphic editor.
Creating 5 thumbnails needs more time than only 1.

This will significant increase:
- the time for the initial display at the file list
- the time for deleting files
- the size of the thumbnails database

I read a lot of threads here in the forum about blaming the very slow deletion and file display times.
If you can live with significant slowdowns, I won't ...

I prefer to just press Ctrl-Q on a file of interest and see it just large and bright on request.

[Matthias030]

- the time for the initial display at the file list

If you switch to thumbnail view then it is identical than before. It reads only 1 thumbnail size and use 1 database. The speed should be the same. I prefer for every thumbnail size an own database. So if you change thumbnail size then another database is used. Of course after changing sizes, TC needs another time to read new icons. But if all icons are stored in database then it is faster next time.

I think it is a good addition to the currently implemented thumbnail view. Everything works as before. And for those who want use other sizes must accept the time for icon rereading.

- the time for deleting files

Icons can stay in databases. From time to time you manually compress databases in TC configuration and remove unneeded thumbs. So file deleting should not be slower.

- the size of the thumbnails database

Now you need 5 databases. But only one database is active at one time. Nothing is slower than before. and harddisk space is not a problem in current times.

[sqa_wizard]

Icons can stay in databases.

Thumbnails are copied and deleted with files by default, which in fact will increase copy time a little, but deleting time significant.

If you switch to thumbnail view then it is identical than before. It reads only 1 thumbnail size and use 1 database. The speed should be the same.

The initial display is very time consuming, because individual thumbnails have to be created once.

Now you need 5 databases. But only one database is active at one time.

I agree, for displaying there is no speed difference with separate databases.
For deleting this approach needs to open, search, delete and close multiple databases for each file ! (same goes for copy files)
This results in a significant loss of performance for copy and delete tasks.

[Balderstrom]

Well, please take in account, that thumbnails are not coming with the file, but have to be created for each file separately !

Only because that is how TC has it implemented. JPEG's have been able to store thumbs inside the file itself for a long time: it can be placed into the EXIF header.

Unfortunately, Irfan (Irfanview) refuses to implement updating the EXIF data as such. Or exporting it's thumbs to a database -- which makes Irfanview's speedy thujmb creation kinda useless. One need's to utilize XnView to update the EXIF header embedded thumb.

[sqa_wizard]

JPEG's have been able to store thumbs inside the file itself for a long time: it can be placed into the EXIF header.

Sure, but there are a lot of other file types out there.
Graphic ones as well as others like PDF.

Copy and delete processes have to open all databases for each file type, just to check if there is a thumbnail to consider.

[Matthias030]

JPEG's have been able to store thumbs inside the file itself for a long time: it can be placed into the EXIF header.

Here is a plugin for TC that uses EXIF-thumbs in thumbnails view. I tried it out some days ago http://www.totalcmd.net/plugring/decftumb.html
Speed is unbelievable fast. But one thing is really disappointing: If you manipulate Jpeg (rotating etc.) with some image editor that doesn't update EXIF thumbnail, then displayed thumbnail is different to real picture. However TC could offer this EXIF-Thumbnails as an configuration option.

For deleting this approach needs to open, search, delete and close multiple databases for each file ! (same goes for copy files)
This results in a significant loss of performance for copy and delete tasks.

Ok. Maybe this could be negative for some users. For me it would be not a big problem. I use thumbnail view mainly for browsing through my familiy photos. All JPEG. Rarely I also browse through ico and bmp folders. For copy and delete jobs I usually use TC default view without thumbs. I don't use thumbs view for other filetypes. It is useless for me.
I only need thumbs view for viewing and want to increase and decrease picture sizes.

However it would be great if Mr. Ghisler improves thumbnail view. TC is the best file manager, for thumbnails the windows explorer is better. But i hate windows explorer
Maybe there are other possibilities to realize a faster thumbview in TC. What about a thumbs_tc.db file in every picture folder, like win explorer does? It don't really like these files in every folder, but if it helps thumbview to become better, then I would use it.