automatically resize the app icon instead of issueing the warning that the app icon will be resized

Sorry, it's the icon for the sleep coach glance, not the nap glance.

For example, here's the Garmin nap glance icon (40 x 40, taken from a FR955 screenshot):

Here's what it looks like after resizing to 33 x 33 using nearest neighbour (no colour blending):

Pretty bad, right? Sure, I can get better results with a better resizing algorithm that blends the colours of neigbouring pixels, but that would probably require more colours than a MIP device has (64).

Nonetheless, I tried it:

Looks great, right?

I expanded the image canvas size to 40 x 40 (pixels were added without changing any of the existing pixels), and set the new pixels to black, then used this image as a launcher icon for a device app.

I tried it out on my fr955 and took a screenshot:

This looks noticeably bad to me (certainly worse than the original icon), both on the real device and on my computer monitor, especially when it comes to the Zs. I think this would be the case for any sharply defined elements (like letters or numbers).

Also, if no one cares about automatic launcher icon resizing, why did Garmin add the ability to use SVG files? Perhaps for people who want their icons to be automatically resized *and* look good?

> This icon is so small, that this really does not matter much

As I tried to argue, in a sense the fact that the icon is so small (with so few pixels, at least on MIP devices) is actually an argument that resizing is less effective here. Sure, on the one hand most ppl are not looking too hard at the icon. On the other hand, the fewer pixels you have, the less information you have to work with, and the less information that's remaining after resizing (down to a lower resolution). A 40 x 40 icon that looks great may not look so good when auto-resized to 33 x 33 for a device that uses 40 x 33.

Even flocsy conceded that he would be ok with the warning when icons are resized up to a higher resolution, possibly indicating that some may care about how their icons look and that automatic resizing may not be appropriate for all people in all circumstances.

You also completely ignored my argument about different aspect ratios though (e.g. 40 x 40 => 40 x 33). There are 3 conceivable ways to handle this automatically, none of which are ideal:

- crop to fit. This is obviously bad for ppl who don't want their icon cropped (probably most ppl)

- resize to fit, without preserving aspect ratio. Bad for ppl who don't want their icon distorted. In fact, this is what happens with the store website (last time I checked), when you upload a non-square listing image. There's so many apps with distorted listing images for this reason

- resize to fit, preserving aspect ratio. This is the best option (and probably what Garmin does), but now you'll have empty space around your icon (which could make it appear noticeably smaller than system launcher icons). e.g. if your 40 x 40 icon is resized to 33 x 33 on a device that uses 40 x 33, and all the system launcher icons are 40 x 33, your icon will appear nearly 20% skinnier than most of the other icons.

> I think what flocsy proposes "have a big app icon automatically resized to a smaller resolution" is the most sensible solution.

Except the compiler already does this, doesn't it? It's right in the warning: "Image will be scaled to the target size."

Even the title of this bug report isn't quite right: "automatically resize the app icon instead of issueing the warning that the app icon will be resized"

Asking for "X instead of Y" implies that X is not currently happening, except that we all know it is.

> I feel the build should (always) be catered for the majority of people, not for a minority.

If the majority of people don't use type checking, should type checking be disabled by default? Look at how the "default" forum advice is always to turn off type checking if you're having a problem.

Look at all the apps that have weather support which are now crashing because they don't handle the case where observationLocationName is now null. Sure, some of them may have been created before type checking existed, but the field has always been documented to be possibly null. If most devs don't follow the documentation, should Garmin just not care about writing good documentation? (Yeah I know there's a good joke in there somewhere.)

> In fact I'd like to meet the developer that cares about automatic resize of the app icon

Meet flocsy: "I'm ok with the warning, when it needs to size up"

Nonetheless, I upvoted this bug report.

This icon is so small, that this really does not matter much. In fact I'd like to meet the developer that cares about automatic resize of the app icon. On all app developers uploading to the app store, it would surprise that you find more than a handful.  //

> If and when this is implemented, then Garmin could also add a flag to treat warnings as errors (for those who want the cleanest build possible).

in my book compiler flags are hardly ever a valid solution, it should be clean out of the box.

// ok joking aside you gonna probably find more than a handful that want to pixel edit the app icon in all it's possible resolutions, but this will still be a minority. I feel the build should (always) be catered for the majority of people, not for a minority.

I think what flocsy proposes "have a big app icon automatically resized to a smaller resolution" is the most sensible solution.

> For that matter, maybe every compiler warning should have a corresponding flag which suppresses it.

If and when this is implemented, then Garmin could also add a flag to treat warnings as errors (for those who want the cleanest build possible).