On Wed, Jan 12, 2011 at 7:36 AM, Ken Thomases ken@codeweavers.com wrote:
On Jan 11, 2011, at 2:41 AM, Damjan Jovanovic wrote:
The 256x256 pixel icons are designed to be viewed in that size. They can, and often do, contain a different picture to the smaller icons. When you scale them down to a smaller size, they look bad. On MacOS that may not matter since multiple icon sizes are written and the best is chosen, but on freedesktops we only write 1 icon size at the moment, and then it gets scaled to something like 64x64, so it really does make a difference.
OK. I'll alter my patchset to be restricted to just Mac OS X. Thanks for the heads-up.
Personally, given what you say, I think the freedesktop-targeted code should obtain the actual height and width and then make its logic for picking the best size explicit about rejecting larger icons. That is, it shouldn't just pick the apparently-largest icon and rely on 256x256 being "accidentally" zero-sized.
Also, is it common for Windows icons to contain 64x64 variants? My impression is that it's not, but I have no hard data about that. In that case, it's typically better to scale down from a too-big icon than to scale a too-small (e.g. 48x48) icon up. So, the freedesktop-targeted logic for picking a best size may want to pick 64x64 if present, the smallest size larger than that if available, then the largest size smaller than it as a last choice.
My argument wasn't just about quality, it was also about the picture that's shown: the eMule 256x256 picture is different from the 64x64 picture, resulting in an icon that users wouldn't see on Windows AFAIK.
On Gnome desktop icons look like they're 64x64, menus look 32x32 or less.
The real solution to all this on freedesktop is to write each icon size into 16x16, 24x24, 32x32, 256x256 and such subdirectories under ~/.local/share/icons/hicolor/, then decipher the complicated semi-broken logic of the icon theme spec and the xdg-icon-resource tool's code (and probably Gnome's source code too) to figure out how on earth they get Gnome to read those icons immediately. In my tests with icons written this way, Gnome starts with a blank icon, then refreshes to the actual icon only minutes later and only under mysterious circumstances. Given this shakiness of icon handling, KDE, XFCE, LXDE, and others will also require individual testing.
(You have to wonder why they had to pick single-image PNGs and then require elaborate standards and filesystem layouts and multi-prefix searches to support different icon sizes, followed by advanced caching strategies to offset the abysmal performance, instead of just picking a multi-image icon file format like Windows and MacOS did.)
Anyway I'll try to spare some time for it this weekend.
Regards, Ken
Regards Damjan