My application icon does not show high density version while changing folder view settings that contains my application, however my icon contains 32, 48, 64, 96, 128 pixels.
Any help please?.
You need to provide a 256x256 pixel version in your icon file.
Windows doesn't use 96x96 or 128x128 pixel icons, and the 32x32 and 48x48 pixel versions are only used when those sizes are called for in the UI. They are not scaled upwards because the result would be pixellated and horrible-looking.
The minimum icon versions that must be provided in a Windows ICO file are:
256x256, 32-bit color (PNG compressed)
48x48, 32-bit color
32x32, 32-bit color
16x16, 32-bit color
48x48, 24-bit color
32x32, 24-bit color
16x16, 24-bit color
You can include the other sizes if you want. It won't hurt anything. And there might be components in the shell or elsewhere that use those sizes. I can't remember all the rules, they're too complicated. But larger versions of the icon will always be scaled down when the exact size is not provided.
If your application needs to be accessible in "Safe Mode" or somewhere where only the lowest common denominator of video drivers will be available, I also recommend including 8-bit or 4-bit color versions of your icons. Don't spend too much time on them, though; use an icon editor that can automatically generate them, and then clean them up if necessary just so that they're recognizable. And you only need these low-bit-depth icons for the small sizes.
Related
My app has a toolbar which is normally 64 pixels height. On OS X (with a retina display) the toolbar's height still equals to 64 (logical) pixels.
If I pass 64x64 bitmap when creating a wxBitmapButton I get a blurry image (which is expected), so I need to pass somehow a 128x128 bitmap.
When I pass it, it's just shown cropped without proper scaling. So how can I use wxBitmapButton to show high-quality bitmap?
I know this is a rather old question by now, but there is finally a good answer to it now if you're using the latest versions of wxWidgets from Git or 3.1.6+ once it will have been released.
The answer consists in using wxBitmapBundle which is basically a smart container for bitmaps to be used in different resolutions/at different DPI scale factors. In the simplest case, which is sufficient under Mac, you just need to create a bundle from the two bitmaps, to be used at normal (or 100%) and high (or 200%) DPI by using wxBitmapBundle::FromBitmaps(bmpNormal, bmpHigh) and pass this object to wxBitmapButton::SetBitmap().
This also works with wxToolBar tools, wxStaticBitmap and other (although not yet all) classes. And the bitmap bundle can be created from resources, which is especially convenient under Mac, as you can just have normal.png and normal#2x.png files in your application bundle (which has nothing to do with wxBitmapBundle, it's just an unfortunately overloaded term) Resources subdirectory.
I'm working on porting a graphics system based on CoreGraphics to use Metal instead. However, I've noticed that there seems to be some kind of color system mixup when I load .png files that do not have an alpha channel. .png's with an alpha channel work fine, although I have to do some swizzling as my Metal context uses BGR colors. When I load and display a texture from an alpha-less .png, the color components appear to be out of order. Textures that were supposed to appear red appear blue and vice-versa, leading me to believe the order of the color components has been swapped.
Does anyone have any idea why this might be happening? There was no issue on the previous CG-based system.
wxWidgets 3.1 claims to fix the Windows High DPI issues. It works too but I see blur UI (fonts/bitmaps) looks stretched.
I went through the https://learn.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows
I did the manifest changes to make my application DPI-aware, it removed the blur effect but application layout went wrong, every layout looks smaller (unusable UI).
Note* issue more vigilant on 3K and 4K system. Hardcoded pixel sizes are not scaling (like 400px width button, 500pixel width panel etc).
wxWidgets gives you a (relatively simple) way to make your application work in high DPI, but doesn't -- and can't -- do it automatically for you, in particular only sizer-based layouts without hardcoded pixel sizes will work correctly and you do need to provide your own higher definition artwork.
Concerning the existing pixel values, the simplest (even though not really the best) way to make them work better is to put FromDIP() calls around them.
Also note that you don't need to do anything special for pixel values in XRC, they're already interpreted as being resolution-independent pixels and are scaled according to the DPI automatically.
When one looks at the Guidelines for fonts, we see that fonts are specified in points. A point is 1/72 of an inch so it is an absolute measure: a 10 points character should show at the exact same absolute size on any monitor at any resolution. That would make sense to me as I want to be able to read text -at the same size- whether on a 10 in tablet or a 23 in monitor. In other words, I want my text to be readable on a tablet, but I do not want it to be too big on a monitor.
On the other hand, I can understand that some UI elements could be specified in pixels, as in the Page layout guidelines.
However, in XAML font size is specified in pixels which is device dependent (to my understanding). Hence the fonts size will look tiny on a monitor with a higher resolution! See this post for more details. The answer in that post says "this way, you are getting a consistent font size". I can't see how I am getting a consistent size when it changes when the resolution changes?!?
Should I load different font size programmatically depending on the resolution of the device?
I see here that Windows does some scaling adjustment depending on the DPI. Will this adjustment be enough for my users to have a great experience on a tablet and on, say, a 20 inch monitor (or should I programmatically change the font size depending on the device resolution)?
Bonus question: WHY are the Font Guidelines written using points when the software tools do not use points (like, what were they thinking)?
"What were they thinking" is extensively covered in this blog post.
You'll also see described how scaling for pixel density is automatic:
For those who buy these higher pixel-density screens, we want to ensure that their apps, text, and images will look both beautiful and usable on these devices. Early on, we explored continuous scaling to the pixel density, which would maintain the size of an object in inches, but we found that most apps use bitmap images, which could look blurry when scaled up or down to an unpredictable size. Instead, Windows 8 uses predictable scale percentages to ensure that Windows will look great on these devices. There are three scale percentages in Windows 8:
100% when no scaling is applied
140% for HD tablets
180% for quad-XGA tablets
The percentages are optimized for real devices in the ecosystem. 140% and 180% may seem like odd scale percentage choices, but they make sense when you think about how this will work on real hardware.
For example, the 140% scale is optimized for 1920x1080 HD tablets, which has 140% of the baseline tablet resolution of 1366x768. These optimized scale factors maintain consistent layouts between the baseline tablet and the HD tablet, because the effective resolution is the same on the two devices. Each scale percentage was chosen to ensure that a layout that was designed for 100% 1366x768 tablets has content that is the same physical size and the same layout on 140% HD tablets or 180% quad-XGA tablets.
Right now, I have a couple fonts: HoboStd20.fnt which points to HoboStd20.png and Teen40.fnt which points to Teen40.png
However, I need retina display fonts.
How do I go about inserting these bitmap fonts into the app?
Do I need to create a font that is twice the size of the original fonts?
How should I name the fonts? Do I rename both the png and fnt file like this: HoboStd20-hd.fnt?
Thank you!
The basic routine is to design your bitmap font at either SD or HD resolution. Then re-export the same font with double or half the font size.
For example, when I design fonts using Glyph Designer (highly recommended), I first create the Retina font and save it as font-hd.fnt. Let's say this has a font size of 40 points. Next I set the font size to 20, and re-export the file as font.fnt.
In cocos2d you reference only the font.fnt file. It will automatically load the font-hd.fnt file on Retina devices.
Sounds like you're using Angelcode's BMFont to generate the fonts (are you?).
Are you using alpha-tested edges for these fonts or using a distance-field based rendering scheme?
This paper called "Alpha-Tested Magnification for Vector Textures and Special Effects" might help you get acceptable quality without having to double the size of the font/texture.
That said, if you are using BMFont (and can write shaders to unpack pixel data) - it is also possible to pack multiple pages using one bit per page or one channel per page. This + alpha tested + distance field should give you pixel-perfect quality for text.