You haven't really missed anything, these are around your only real choices. The only other real option is using something like the UWP XAML, but that isn't ready for desktop applications yet. You can use a mix of these, provide assets for various sizes and then scale down from the next largest one if you don't have an exact match. As an example, I have quite a few icon sizes in each of my icon files to match various DPI settings.
But yes, the pain that you feel is the same pain that everyone who jumped aboard the high dpi train has felt.
MFC dialogue boxes for High DPI
Apologies if this has been discussed here before - if so, I couldn't find it.
I am belatedly coming round to high DPI. Doing nothing has been OK up to 150%, but it definitely isn't at 250%.
I have a standard MFC app with DPI awareness set. The feature-pack ribbon bar automatically stretches nicely without too much bluriness, so I can worry about that another day. The dialogue controls size themselves nicely (as does text thereon).
The most immediate failing is that bitmap and icon images on dialogue buttons and picture controls do not stretch automatically; that is up to me. They were designed for 96dpi, and with dpi at 250% of this, they're 2/5 the expected size - almost unreadable. So what do I do?
So far I have a number of methods, all with disadvantages.
a) provide different sized bitmap resources for every image and use the most appropriate size.
But my new laptop's settings indicate that dpi might be 100%, 125%, 150%, 175%, 200% 225%, 250%, 300%, 350%, 400%, and presumably this will continue as technology improves. Even providing for every other size, and using the next smallest image where one is absent, feels like a vast, and inelegant, inflation of resources.
b) Use vector graphics. (EMF resources) on picture controls and owner-draw buttons.
I am now happily loading emf resources. This is great for high enough DPI, but with intricate line-images this doesn't work at 96dpi: lines on the image miss the screen pixels and get omitted.
c) Stretch-blit bitmaps on owner-draw buttons.
Ultimately I want to abolish all blurriness, so I don't want to go down this route.
d) Draw symbols as text from the private-use area of an appropriate open-type font. This again is scalable, and is an option available to me for music symbols which my program already manipulates. But even so it has limited applicability.
So what do people here do? Have I missed something, or is it just a choice between (a) and (b) in each case? Does anyone else feel guilty about adding megabytes of bitmap/icon resources?
Dave
-
Darran Rowe 1,041 Reputation points
2020-08-18T12:54:11.24+00:00
1 additional answer
Sort by: Most helpful
-
David Webber 136 Reputation points
2020-08-18T13:41:52.16+00:00 Thanks for this - but a question following your comment:
If you have an icon CButton, and supply an icon containing the image at assorted sizes, does the best size (for the DPI in use) get chosen automatically?
Dave