I noticed that my app sends icons to the Windows tray with a size of 16x16 pixels--and my Vista PC I've got a doublewide taskbar that appears to show icons at 18x18. The resizing artifacts on my app's icon look awful. How can I ask Windows what size the icons should be?
Edit
I'm generating the icon dynamically, with a pixel font text overlay. It seems wasteful to generate a bunch of icon sizes dynamically, so it would be nice to avoid building an icon with all the "possible" sizes (not that I'm even sure what those are).
GetSystemMetrics(SM_CXSMICON) returns 16--the incorrect value.
GetThemeBackgroundContentRect didn't help, either.
Create your icons in multiple formats, and let Windows select the one it wants.
Here's the Wikipedia article on the .ico format.
If you really need to know, GetSystemMetrics with a parameter of SM_CXICON or SM_CYICON will tell you the width and height that Windows wants to load.
Mark's core answer is the right one: Create your icons in multiple formats and let Windows choose the right one. Don't forget to do 32x32 and 64x64 icons for HighDPI scenarios.
But SM_CXICON/SM_CYICON won't necessarily return the size that will be used in the taskbar. The taskbar chooses the right icon size for it's size (this is much more important in Window 7).
Just provide appropriately sized icons and you should be ok.
Your best bet may be GetThemeBackgroundContentRect passing TBN_BACKGROUND as iPartId for the tray notify background.
GetThemeBackgroundContentRect should return the size defined by the current theme that may be used for drawing without overlapping the borders of the parent element. If I'm reading this correctly, that would be the largest sized notification icon permissible and presumably the size that is being used.
Testing with multiple DPI settings is probably the easiest way to tell if this is returning the correct value.
Per the NOTIFYICONDATA documentation:
If only a 16x16 pixel icon is provided, it is scaled to a larger size in a system set to a high dpi value. This can lead to an unattractive result. It is recommended that you provide both a 16x16 pixel icon and a 32x32 icon in your resource file. Use LoadIconMetric to ensure that the correct icon is loaded and scaled appropriately. See Remarks for a code example.
...
...
// Load the icon for high DPI.
LoadIconMetric(hInst, MAKEINTRESOURCE(IDI_SMALL), LIM_SMALL, &(nid.hIcon));
...
So, creating icons dynamically really isn't the best option. You should provide multiple icons of different sizes statically in your program resources and let Windows choose the best one it wants.
Related
I've set my electron app icon by converting a 2014x1024 png to icns using this: https://github.com/bitboss-ca/png2icns
However, my icon looks every so slightly bigger than all the others in the "taskbar" on macOS (comes up when you cmd-tab).
Do I need to give my icon some sort of padding or something? How can I make it the same dimensions as other icons?
There doesn't seem to be any guidance on this, only on file formats and ideal dimensions (which I've adhered to already).
I'm trying to set an icon for my app, however the icons derived from the original image are pixelated and look bad. I tried to provide the app icon gear application with images of different sizes, however the result is still unpleasant.
Should I provide it with images of higher resolution or lower resolution to get better results?
The answer to this question links to to a matrix provided by Apple for icon sizes. Should I use these sizes strictly, consider them as a lower border not to go under, or consider them as a ceiling not to exceed?
The docs states
Table 45-1 lists the sizes required for these custom icons and images.
Use the exact sizes.
I couldn't find it on Icon and Image Sizes.
But I mean, what is the size of following icons?
Below mentioned article, there is a note:
Once you download this, you will see that there is a recommended size:
104x104 for 3x
70x70 for 2x
Since Apple will automatically size and re-colour the icons, it's better to use a PDF, which has the added benefit of looking sharper and a reduced risk of causing clipped edges if margins aren't used.
Here's a comparison of PDF vs PNG (exact same icon, originally and SVG exported from Sketch):
The size is also the same.
In Delphi XE2, I have a JvGIFAnimator component (from JVCL) on a form. Now, when I run this program on a computer where the Windows DPI Display Settings are set to 125%, while all other GUI elements and system text are scaled up to 125%, the GIF animation unfortunately is not resized. The GIF is embedded in the JvGIFAnimator component with the TJvGIFAnimator.Image property at design time as a TJvGIFImage.
Is there a way to rescale the embedded GIF at run-time according to the Windows DPI Display Settings?
You'll have to do this yourself one way or another. There is nothing built in that will automatically rescale. Options include:
Decode each frame of the GIF. Use a graphics library to resize the images. Create a new GIF with the resized images.
Provide multiple GIFs at different sizes and use the one with size closest to the target.
Of these options, the latter is better. Resizing on the fly will lead to horrid visual artifacts and aliasing. Your animation will look dreadful. Not to mention all the coding involved. Choose option 2.
In fact, this issue is no different for rasterized animations as it is for rasterized static images. Just as you need to provide multiple glyphs for toolbar buttons, you need to supply multiple versions of your rasterized animations.
The BB OS 5.0 supports images for context menus. The API documentation says the image will be scaled to fit a square set by the height of the menu font. I find that totally unhelpful.
The only way I can explain that method of calculation is due to screen resolution and DPI. But since the 5.0 OS is only valid on a handful of devices with similar screen sizes, I reckon they can specify the actual icon size they use.
I'd like to choose an icon size that's closest to the default menu font height so that the they look OK.
What size do you use? Do you even use this feature?
I haven't used it yet, but I would recommend using any square ratio maybe up to 64x64; the problem is that with new devices on the horizon (eg rumored tablet - with much bigger display) it won't necessarily be practical to target a specific screen size.