No, it generates thumbnails outside the main UI thread; sometimes it's a bit slow in so doing, but I've never seen it hang an Explorer window, regardless of file size or quantity. (Windows 7, but it would astonish me to learn that 10 displays a regression here.)
> No, it generates thumbnails outside the main UI thread; sometimes it's a bit slow in so doing, but I've never seen it hang an Explorer window,
As an example of the contrary, I've seen misbehaving third party thumbnail-providers cause Windows explorer to crash entirely.
Only way to "fix" it was to install the software which added the thumbnail-provider, or go into the folder via cmd.exe and rename the file you "knew" caused issued to a different extension while doing the operation you originally came to do.
That may have been on Windows 7 though. I don't know for sure if this weakness still exists in Windows 10.
If the third-party thumbnailer is implemented as a shared library (DLL) that Explorer is configured to load, then sure, a segfault or similar in the library will kill the whole process. Not sure how that's Microsoft's fault. Sure, there's an argument that loading a library is the wrong model, but there's a performance tradeoff, especially given Windows' relatively slow IPC capabilities. The real surprise here is that Linux manages to be comparably slow, but when you complicate a simple, fast IPC model with dbus and a million other middleware layers, I suppose it starts to make more sense.
I'm not excusing the Linux implementation for being slow, which I agree it sometimes is (Hello Dropbox and my huge, flat "Camera uploads" folder...).
I'm just saying that I've seen bad things happen on Windows too. Not blaming Microsoft, just saying that in a typical end-user scenario with lots of randomly installed software, you will have Explorer break too.
That's not the problem, most DE file managers use an external process too (via dbus), but it's still slow, even on an SSD or when the cache has alredy been generated.
They're also buggy, XFCEs thumbnailer thumblerd (also used in LXDE and probably others) used to have memory leaks when it encountered video files with unknown codecs, newer versions re-scan the entire cache every time you delete/move a directory, making quite a bit of disk IO.
I've found simpler file managers like rox-filer, pcmanfm to be much faster at thumbnailing.
There's a suggestion that that has less to do with inherent issues and more with wanting to display more information than can be obtained from whatever the Windows API calls stat(2). An indexer can actually help a great deal here, but I don't know if that's actually the issue - I should be getting a work-issued Windows 10 box pretty soon here, and look forward to experimenting for myself.
That said, even the slowness under discussion doesn't actually hang the UI thread. That's something you have to be pretty special to get so badly wrong, in this day and age where even web devs are learning better than to do expensive work in the main thread, and have the tools available to avoid doing so.
In everything from XP through 7, you can. Select the view you want to make default, then press Alt to display and activate the menubar. In the Tools menu, choose Folder Options; on the View tab, click Apply to All Folders. Current Explorer windows may need to be closed and reopened to show the change; all newly opened windows from now on will take the view you chose as their default, but also remember any changes you make to a given folder's view.
I generally prefer Details view myself, but know no reason why this shouldn't work for List or any other. Enjoy!
No, it generates thumbnails outside the main UI thread; sometimes it's a bit slow in so doing, but I've never seen it hang an Explorer window, regardless of file size or quantity. (Windows 7, but it would astonish me to learn that 10 displays a regression here.)