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.
Install eMule and see its icons on Gnome as an example.
On Tue, Jan 11, 2011 at 5:48 AM, Ken Thomases ken@codeweavers.com wrote:
The existing code would always prefer a smaller icon because it was misinterpreting 256x256 icons as 0x0.
programs/winemenubuilder/winemenubuilder.c | 32 +++++++++++++++------------ 1 files changed, 18 insertions(+), 14 deletions(-)
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.
Regards, Ken
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
On Jan 12, 2011, at 3:22 AM, Damjan Jovanovic wrote:
On Wed, Jan 12, 2011 at 7:36 AM, Ken Thomases ken@codeweavers.com wrote:
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.
I understood that. So, if an ICO has a 64x64 size, then definitely use that. But if an icon has sizes 48x48 and smaller plus 256x256, and if the desktop will display it at 64x64, then it doesn't seem that scaling the 256x256 size down is less correct than scaling the 48x48 size up. Neither will result in a "correct" or "incorrect" 64x64 image because there's no such thing specified by the ICO. Given that there's no correctness advantage, I would think quality would be preferred.
Of course, it's just my opinion. And, since I don't use Linux, I have no stake in the matter. So, I'm happy to let others decide. (I still think the logic, whatever it is, should be explicit about handling the 256x256 variant, when present, rather than leaving it to an accident.)
Cheers, Ken
-
Damjan Jovanovic -
Ken Thomases