PureBasic Forums - English

When switching Windows 7 to large fonts, it seems to fully upscale the whole window, all gadgets etc. In other words: under Windows XP I open a window at 10,10 with a size of 100,100. When opening the same window under Windows 7, with fonts set to large, it appears that Windows 7 (Aero?) upscales everything, except the screen coordinates, ie. it opens at 10,10, but the window is way larger, and so are the fonts being used...

Is it possible to *disable* the upscaling mechanism (for my specific applciation) or is there a way for me to see how much it is going to be upscaled by Windows 7?

blueznl wrote:When switching Windows 7 to large fonts, it seems to fully upscale the whole window, all gadgets etc. In other words: under Windows XP I open a window at 10,10 with a size of 100,100. When opening the same window under Windows 7, with fonts set to large, it appears that Windows 7 (Aero?) upscales everything, except the screen coordinates, ie. it opens at 10,10, but the window is way larger, and so are the fonts being used...

Is it possible to *disable* the upscaling mechanism (for my specific applciation) or is there a way for me to see how much it is going to be upscaled by Windows 7?

Do a search on scaling and Vista: you'll get plenty of answers.

Yeah, found many, but haven't found anything that I could turn into code yet. Otherwise I wouldn't try my luck here

blueznl wrote:Yeah, found many, but haven't found anything that I could turn into code yet. Otherwise I wouldn't try my luck here

From what you describe I assume you do not mean large fonts in the UI but the DPI-scaling.
Instead of disabling it ( overriding the user settings .. ) I simply adapt like this:
This leaves the scaling intact, it just corrects font size.
Compile with XP skin support on. Does it for me on Vista and W7.

Hmpf. I think I'll have to add some pictures, as it appears I'm not expressing myself clear enough. Don't worry, that happens a lot to me

Ah! Found it! Or this is what I could figure out thus far... If I made a mistake, or someone has additional info, please reply as I think about turning this into a Survival Guide page.

Here's what happens (I think):

Windows 7 and Vista have an 'XP-style DPI / XP compatible DPI scaling mode' (or whatever you want to call it). By default, XP, Vista ad Win7 are set to 96 DPI.

On XP, changing the DPI does change the elements of the Windows GUI, as well as the size of fonts being drawn even those inside a PureBasic program. On Vista and Win7 you can disable 'XP style DPI' and then suddenly everything changes...

In addition, on XP you can als set the font to 'large' but this does not affect the DPI, it only affects Windows GUI elements.

In XP-style DPI.

In 'XP-style DPI' everything works like Windows XP (little surprise there):

- DesktopWidth() reports actual screen width
- GetSystemMetrics_() reports actual screen width
- GetDeviceCaps_() reports actual screen width and actual DPI
- GUI elements are drawn using the actual DPI setting
- Windows positions are drawn on given screen coordinates
- Fonts are drawn using a font based on DPI setting

The above can lead to a surprise when you change the DPI settings and draw a font, so you have to adjust the font size using GetDeviceCaps_(), but that's it. Frankly, I think font size shouldn't change with a different DPI setting, as no gadgets are resized in XP-style DPI mode.

It seems anything above 120 DPI (144 DPI?) is considered 'high DPI' and might yield different results but I'm not totally sure yet. Still looking into it

Non XP-style DPI.

With XP style DPI disabled things work differently: now everything which is not 'high DPI aware' is going to be resized / scaled automatically, or at least that's the concept Some values will be adjusted accordingly, so if DPI is set to 150 in non-XP mode, your application on a 1680x1050 screen will be 'enlarged' as if the screen was only 1075x672 pixels.

- DesktopWidth() keeps reporting actual screen width
- GetSystemMetrics_() reports the adjusted screen width
- GetDeviceCaps_() reports the adjusted screen width and always 98 DPI
- GUI elements are drawn using the real DPI setting (pro rato upscaled)
- Windows positions are drawn on adjusted screen coordinates
- Fonts are pro rato upscaled

For all practial purposes, your application runs as if it was running on a Windows XP box with a different screen size and a DPI of 96. Unfortunately, except for WinApi, there's no way to find out the 'adjusted' screen size, as DesktopWidth() reports the physical screen size regardless of DPI settings so if you're using DesktopWidth() and its brethern be aware...

High DPI aware code.

Still working on this one, but to use high DPI values you seem to have to do a bit of additional work outside of your code.

blueznl wrote: For all practial purposes, your application runs as if it was running on a Windows XP box with a different screen size and a DPI of 96. Unfortunately, except for WinApi, there's no way to find out the 'adjusted' screen size, as DesktopWidth() reports the physical screen size regardless of DPI settings so if you're using DesktopWidth() and its brethern be aware...

What is wrong with using WinApi?
Perhaps you should attach a picture to clarify the problem. Keep in mind that dpi-aware programming is what MS expects from us ....

Well, IMHO PureBasic should be reasonably self contained, leaving the WinApi stuff for experienced coders and special purposes.

I'm working on a Survival Guide page with some images. Have you ever tried setting DPI to 200 and run some code on it? (Turn XP-style DPI off.) Interesting results

And here are some examples for the non-believers (scroll down and look at the last two images)...

http://www.xs4all.nl/~bluez/purebasic/p ... 17.htm#top

Which is what prompted me to add a feature request here...

http://www.purebasic.fr/english/viewtop ... 21&start=0

@bluezl

This is probably the best thread on the forum about this (not just because it's my thread), reading the conversation in the thread should give more understanding on how this work.
Or if your just lazy, try out the example source in the first post.

http://www.purebasic.fr/english/viewtop ... 7&p=310974

Thanks for the link, Rescator, I must have missed it at the time. I'm going to study it and see where I got things right and where I have them wrong

The Survival Guide typically grows whenever I run into an issue myself, and DPI / font-sizing was one of them. Perhaps this time I'll simply borrow some of your stuff to save me time

By all means do so. the license in this case is Public Domain, other times it's a very friendly zlib/MIT license,
and if no license is stated at all then consider it Public Domain really, the forum is publicly readable after all

I added that thread to the Windows Forum FAQ to hopefully make it easier to find for others in the future: http://www.purebasic.fr/english/viewtop ... =5&t=34334

Yeah, the devs might consider making that thread sticky, I guess it would help some people.

I still think scaling the fonts down again is just horribly wrong. When users increase the dpi it is because they need larger fonts. If you position your text with the knowledge of TextHeight() and TextWidth() then it shouldn't be a big problem. Yes it looks ugly, but so what if the alternative is that the user simply cannot read it?

Dunno, Trond. I think it's the application that should decide what to do if a user changes the DPI settings. It shouldn't be PureBasic that decides.

Indeed, people increasing the DPI do so with a reason: they want a larger GUI and font, but if the application does not modify its gadget sizes, the result will be horrid.

Assume an application draws a line on the screen, that line would still be the width orginally set by the programmer. According to your logic, on systems setting a higher DPI lines would get thicker as well. That doesn't make sense either.

So, when I build an object of 20 pixels high, and put a text with specified font on it, it's up to me to decide if I want to support a higher DPI setting. If I want to, then I will enlarge my gadgets, as well as increase the font.