I compiled one of the latest wxWidgets samples on MS Windows.
On high DPI display with all setting default text and bitmaps are blurry and less clear comparing to other Windows apps?
Check screenshot
Bitmaps probably not so much, but should fonts scale?
What am I doing wrong?
Related
Almost every source about Win32 dpi says that you need to load new scaled fonts.
I tested a simple application (main window and a child ListView, written in pure WinAPI) on WinXpSP3, Win7 and Win10 and in all cases the OS always automatically set the correct font size (and even non-client areas) both at startup and when changing the system scaling in runtime. The only thing I had to change manually was the size of the windows themselves and the size of the icons in the ListView.
The application manifest contained
dpiAware True/PM
dpiAwareness PerMonitorV2, PerMonitor
And I'm a little confused. It turns out that manual processing of fonts is needed only for owner-drawn controls?
I know XP is old, but I just have to know the issue here.
I don't see a way to provide a popup menu with anything like an icon or bitmap with a mask, only a bitmap. So, if I use a compatible bitmap, it will look transparent when the selection bar is not highlighting it, but when highlighted the entire graphic still shows (with a square button face color around it).
If I use a 32bit DIB with alpha, the transparent item just shows black (whereas Windows 10 handles the transparency fine - I presume Vista and Win7 would, too).
If I manually set all the A's to 0 in the DIB, it is still black (on Win10, the images where color would normally be appear white - I would have thought it would be transparent).
Anyway, was there ever a way to provide an icon (since it has a mask), or a bitmap with mask, to a menu so things like XP can handle it automatically (no owner draw)?
Is there a way to force loading of an .ICO file to be the 256 color version instead of the 32bit RGB/A version? I don't have a 24bit RGB graphic in the .ICO, so maybe XP would pick that if it existed instead?
I know GDI doesn't support alpha in all cases, but sometimes it does, and it appears the Windows version matters as well.
Does someone have a background on this, and can tell if this is a known XP issue with 32bit bitmaps?
On XP you must custom draw but not the entire thing, just the bitmap/icon.
On Windows 95/NT4 the only way to do this properly is to custom draw the entire menu item. Before Vista the menu look only changed once, the addition of flat menus in XP, so custom draw everything is certainly possible.
Some time around Windows 98/2000 the ability to set MENUITEMINFO.hbmpItem to HBMMENU_CALLBACK was added. Use DrawIconEx or a image list.
Vista added support for 32bit ARGB bitmaps. You should not use the callback method here because that will disable the new visual style.
See also:
Themed menu’s icons, a complete Vista and XP solution
MSJ cool custom draw
Can I change Qt Creator's (latest version: 4.14.0, Windows 10) general GUI font size (or scaling)?
The problem is, my system display scaling is set to 250% and I have two options for high DPI compatibility in Qt Creator, but both have issues:
I can disable Creator's built-in High DPI Scaling and force System (Enhanced) in the Windows compatibility settings:
Or I can enable Creator's built-in scaling and leave the Windows compatibility scaling override turned off (Application scaling):
In the former case, it's actually a size I find very comfortable except the cursors are all too small and Designer gets wonky (plus it's tricky to layout GUI's because apps all run in System (Enhanced) mode from Creator).
In the latter case, the cursors and Designer work, and it's nice to not have heavy anti-aliasing everywhere, except the GUI font is too large for me, and everything feels cramped (especially the top bar, and the left bar reminds me of one of those old school children's telephones with the huge buttons). Plus the general GUI font is different enough in size from my editor font that the whole thing just feels jarring and kind of stresses me out.
So what I think I'd like to do, ideally, is use application scaling like in the latter example, but just shrink the GUI font size to match the former.
I think I ran through all the options thoroughly, and all I can find is settings for the editor window and the console, but not the rest of the GUI.
To be honest, I'm actually not entirely sure why they don't look the same; my expectation was that Qt's built-in High DPI support would take the scale factor into account in the same way that Windows' System (Enhanced) mode does, but I'm sure it's more complicated than that.
The problem is Qt automatically round up your 250% scaling to 300%. For Qt Creator application, you can create a "QT_SCALE_FACTOR_ROUNDING_POLICY" environment variable, and set it to "PassThrough". You can find details in this question: Qt Creator "too big" on 3840x2160 and 150% scaling on Windows 10.
It's also worth noting that Qt also behaves like this coding a GUI program. This can be fixed with:
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);
We are having a problem with one of our existing Win32 MFC based applications. It does not render correctly on displays that use high dpi settings. More specifically in Windows XP with 120 dpi selected, there are several places in the app where the text scales up but not their containers (text overflowing the bounds of it's button, etc). This also occurs in Windows 7 (and Vista) when >96 dpi is selected and "use XP style dpi scaling" is selected. If xp style scaling is not selected then I understand Win7 uses DPI virtualization instead. Everything looks fine when using DPI virtualization (Ok things are blurry but at least they're correct). By default in Win7 120 dpi uses xp style scaling and the next setting (144 dpi) does not. So our app looks correct at 144 dpi but wrong at 120 dpi.
If I edit the applications manifest to declare the app as "DPI aware" then this turns of DPI virtualization (but not XP style dpi scaling) and this gets me no where. Things still look really bad (no change for 120 dpi, 144 dpi now broken).
I need to fix this problem and I've tried reading up on DPI/scaling issues in general and it has been a learning experience. So far I have not found a suitable solution. At the moment I currently have no intention of doing a thorough and correct fix (the app correctly scales all elements according to the dpi). That would involve a LOT of rewriting. I think there are really two possible solutions. One is turn off any sort of DPI scaling all together. That would mean that if a users Win7 system was set to 120 dpi then everything on their system would look good/big but our app would look correct but would be small compared to everything else in other apps. The second solution would be to some how force our app to use DPI virtualization but to never use XP style dpi scaling. I want this to be an application side change and not rely on end users to have to make Windows configuration changes.
So far I have not found a way to accomplish either solution.
Can someone more knowledgeable on this subject please respond and point me in the right way?
Thanks
You cannot force DPI Virtualization on 120 DPI settings. I have investigated this for a product myself because having the fuzzy look in high DPI seemed a good tradeoff.
We ended up making a full rewrite of the UI positioning and scaling to have it scale properly with the font scaling in high DPI settings. The client is now fully DPI aware and scales properly in any DPI setting.
The work to do this properly took one guy ~3 months in our case for a pretty complex client.
We had a secondary plan that we never tried but it might work for you:
At start-up read the DPI scaling factor of the OS. Then reduce all font instances you have by this factor so that when Windows scales the fonts up again they are back at the size where the UI can fit them. Of course users with high DPI settings will not get bigger fonts in your application but it will at least be usable.
I've learn how to manage different DPI settings the hard way, so that at runtime my applications are properly displayed.
But there is still a big issue with Design time Visual Studio.
Say I build an application at 96 dpi and I switch my display to 120 dpi for testing purposes.
Now IF I open a form designer at 120 dpi, the form is resized according to 125%, the controls moved aso! :-(((
So I try to avoid reopening forms, but that's NOT a nice solution, isn't it?
Is there by any chance a design time setting to prevent form to resize?
Not a solution but possibly a workaround: do not test on your computer but on a VM or other computer and do not open the solution on a computer with big fonts.
And we found that we cannot use the AutoScaleMode = Dpi.Font setting. That will randomly resize forms when we open them in the designer. Dpi or None seem to work.
Although this question is already old, I want to share my workaround.
Keep the Form’s AutoScaleMode = Font. This works fine, if you control the rest correctly.
Set in your Forms Designer: Font = MS Sans; 11px. Basically, specify your Fonts in Pixel, instead of Points. So Visual Studio won't re-scale anything if the system's DPI change.
In the Forms Ctor, after InitializeComponent, re-set: Font = SystemFonts.DefaultFont. Now, at run time, Fonts will use Point-based sizes again, and you get nice high-DPI GUI.
Enable DPI-Awareness, either through a manifest or by API function SetProcessDPIAwareness
You can find the details of my (hard) learning trail on my Blog: http://www.sgrottel.de/?p=1581&lang=en