Notes:

• The images are stored in the blend file uncompressed, increasing the overhead to the file-size from 64kb to 256kb, while it's arguably acceptable, it might be a good time to store the thumbnail with compression.
• By default the thumbnails in Blender's file browser only show 128x128px so this benefit is limited to when users view large thumbnails.
• The note about scaling back up to 256 is an implementation detail that thumbnails are always written to 256x256 size, we could write smaller images, but this means keeping a second set of cache, see D9412: Cache normal/large thumbnails based on display size.

@Campbell Barton (campbellbarton) - Notes:
The images are stored in the blend file uncompressed, increasing the overhead to the file-size from 64kb to 256kb, while it's arguably acceptable, it might be a good time to store the thumbnail with compression.

Yes, it might be nice to store those compressed. Although without doing so this just means that a blend file will be only 196,608 bytes larger, or so.

By default the thumbnails in Blender's file browser only show 128x128px so this benefit is limited to when users view large thumbnails.

Whatever is set by us to be the default doesn't really have much bearing on what users ultimately decide to show, or how they will change it throughout their sessions. Not only is the added detail needed for "large" thumbnails, it is needed for "regular" when the scale is larger than 1.0. And for everyone using high-dpi monitors like Retina.

But the best reason for this change is that it is not a change. We have (collectively) already decided how detailed thumbnails should be, by creating them at 256x256 for images, videos, and even for fonts. We'd want them to be at least as detailed for our blends, otherwise our stuff looks worse in comparison.

The note about scaling back up to 256 is an implementation detail that thumbnails are always written to 256x256 size, we could write smaller images, but this means keeping a second set of cache, see D9412: Cache normal/large thumbnails based on display size.

Not sure that simply saving these to the file system in a smaller size serves any purpose. A 256x256 png thumbnail might take up 56k, while a 128x128 version might be only 29k. But you'd have to save both every time because how I am viewing thumbnails at this moment has no bearing on how I might wish to see them later on. Or we'd just save them in the smaller size and we'd be at the same place we are now, with fuzzy thumbnails but saving 27k on the file system.

In D10491#264628, @Harley Acheson (harley) wrote:

Although without doing so this just means that a blend file will be only 196,608 bytes larger, or so.

Are you saying this makes every .blend file 200KB bigger? I think that's too much.

The new logic depends on fixed sizes which are set elsewhere.

It's not clear why 2x and 4x are used in this patch, without knowing the reasoning behind the changes.

Suggest to add defines for THB_NORMAL, THB_LARGE sizes in pixels.

Then the logic of this patch will read much more logically.

As BLEN_THUMB_SIZE * 4, is really intended to be THB_LARGE_SIZE_PX * 2.

... and below ...

IMB_scaleImBuf(ibuf, THB_LARGE_SIZE_PX, THB_LARGE_SIZE_PX);