Changing to "old" target milestone for all bugs laying around with no milestone set.

This still seems to happen with version 2.1.2

The thumbnail spec [1] only seems to define 128x128 and 256x256 images. All we
could do is probably use the larger thumb and scale it down.
Marking as low priority since - taken the quality of the scaled image - we seem
to do bicubic interpolation, which means that the scaled image quality isn't
that bad after all.
This also just affects the desktop, so setting priority to low.

[1] http://jens.triq.net/thumbnail-spec/directory.html

This doesn't affect just the Desktop, there are use-cases for the other windows, too. See https://answers.launchpad.net/ubuntu/+ticket/4285 for an example.

Is anyone against the idea of adding support for SVG thumbnails as well as PNG?

This would completely solve the resolution problem in certain (fringe?) situations, for example SVG files themselves and schematics.

Perhaps even documents with text, currently also thumbnailed in png, could eventually be generated and displayed as svg with some clever "downsizing" to remove unnecessary detail (and therefore reduce processing).

Several comments:

@Christian Neumair:
True, the thumbnail specification only allows (more exactly, defines) two sizes, 128 and 256. However it doesn't disallow not using the cached thumbnails for all display needs. In particular, if an application must display a visual representation of a file (ie, a thumbnail of a picture) of a (much) larger size than 256, nothing prevents the application from actually using the picture directly, bypassing the (too-low-res) thumbnail.

In fact, Nautilus actually does that sometimes. If you use the right-click menu to set the icon of an object (say, a folder) to a certain image, Nautilus _doesn't_ thumbnail that image, but uses it directly. If you then resize the icons (using the zoom button) to something huge, that folder will be displayed using all the resolution of the image file.

Also, the thumbnail specification doesn't prevent us from using a separate cache for larger-sized thumbnails. (We could, for instance, add another folder in  .thumbnails) Since these "huge" thumbnails would only be needed in some cases (eg, when the user set a certain folder's zoom to very high level), that might actually make sense.

@Justyn Butler
I'm not sure the _thumbnail_ idea would actually work with SVG. I mean, the thumbnail is supposed to be some image that is _easier_ to display than the original file. In case of, eg, a SVG file, I doubt there are any reasonably generic algorithms that can take a SVG document (something reasonably complex like a map) and generate an (i) easy-to-display (ii) usefully-scalable SVG file that (iii) is quick to display.

But the basic idea is actually very good and I support it: whenever the requested icon size is larger than the thumbnail, Nautilus should try to use the actual file (scaled-down) instead of a thumbnail (scaled-up) to display the icon. If it also chooses to cache the result (eg, by adding a new .thumbnails/huge directory, or something more private in /var/tmp), very well, that would make sense for some things like big SVG files.

And a final question: does Nautilus at least _use_ the large (256) thumbnails? I have many folders set to high zoom, and I only have normal (128) thumbnails. I don't even have a .thumbnails/large folder on my computer.

As of http://blogs.gnome.org/alexl/2007/10/16/you-can-pick-any-new-feature-you-want-as-long-as-it-is-this-one/ this one has been fixed. Please refer to bug #512905 for the remaining blur problems. Closing as OBSOLETE.

This bug is occurring again for me, is anyone else able to confirm blurry thumbnails on the desktop?
Bug report here:
https://bugzilla.gnome.org/show_bug.cgi?id=690441