Object-Oriented GUI Library

[St_W]

DPI-awareness is especially important for high-resolution displays. Ideally the user of your library shouldn't have to care about the actual DPI settings and your library does all the scaling internally. However, I agree that this causes some troubles e.g. for images as you already mentioned; I can't suggest a nice approach how to handle those either.

Adding a manifest only is not enough AFAIK as you still have to do the scaling of your application (or: your application will be still unusable on a high-resolution display if you don't).

Yes, unfortunately high-DPI support is quite bad in Windows; many applications (even a lot Microsoft applications shipped with the OS) don't support it.

Being able to change the scaling dynamically is (IMHO) only important if one has several displays with different DPI settings. Changing the system DPI setting isn't something a user would do regularly.

[datwill310]

DPI-awareness is especially important for high-resolution displays. Ideally the user of your library shouldn't have to care about the actual DPI settings and your library does all the scaling internally. However, I agree that this causes some troubles e.g. for images as you already mentioned; I can't suggest a nice approach how to handle those either.

Adding a manifest only is not enough AFAIK as you still have to do the scaling of your application (or: your application will be still unusable on a high-resolution display if you don't).

Yes, unfortunately high-DPI support is quite bad in Windows; many applications (even a lot Microsoft applications shipped with the OS) don't support it.

Being able to change the scaling dynamically is (IMHO) only important if one has several displays with different DPI settings. Changing the system DPI setting isn't something a user would do regularly.

Ah, now things are starting to look a lot simpler!

I have ran my debug app (which has a label) with various DPI settings (after signing out and in) and the font was fine. I have not yet tested images, but I'm assuming either they would actually turn out fine, or the programmer would have to create separate images. They would have to do the images themselves. The only thing I should do is scale x,y,width,height measurements of all windows in their respective properties, right?

Thanks for your reply: it's helped me concentrate on the thing I need to be getting on with and given me clarity about the issues described in my post.

[datwill310]

I just want to update the situation on the OGL here.

I have not given up on the project. I haven't been contributing at all to it for the past few months and I am sorry about that.

I have to be honest: I am STILL confused about DPI-awareness. It's basically the only reason why I've been avoiding the OGL as of late (besides the fact that my computer broke and have been busy with other stuff etc.). I thought I got it... I don't.

DPI-awareness is especially important for high-resolution displays.

Having read your post again after trying to get my head round it today, I've really taken into account what was said.

What is the definition of "high-resolution", i.e. what figures are we talking here?

I'm pretty sure I've only got some standard-resolution monitor (it can only go up to 144DPI, 150%, with the screen physical size ratio 3:4. Is this what's considered to be high-def, or should I pay around £200 for an HD monitor to find out?).

As my sarcasm hinted at, I am not willing to pay for an HD monitor. If this functionality will only be essentially important for these types of monitors, I have no way of testing and therefore no way of safely incorporating it into the OGL.

Also, I've tested with 100%, 125%, and 150% scaling, and with the debug app I've got, I don't even need to do anything (except for a sign out, of course!) for:

• Controls to be positioned correctly.
• Fonts to be clear and sharp.
• I've not tested images, but as I have said, the programmer will just have to scale each image they use: which doesn't seem like a tough issue.

I'm am running on Windows 10. Could this be a special feature of the new OS, or am I completely missing the point here?

Also, what parts of my library do I apply DPI-arithmetic to? Parent windows? Child windows? Fonts? All or only some?

Adding a manifest only is not enough AFAIK as you still have to do the scaling of your application (or: your application will be still unusable on a high-resolution display if you don't).

This is telling me that I don't have an HR display, as all the options I have tried with the manifest file only, work. Perhaps this is where my confusing is lying? Or maybe it is to do with not expecting the right thing from changing the DPI setting? What should I expect from a DPI-aware application?

But then I thought: I should look this up myself with the reference you gave me in one of your previous posts. And I come up with the following:

• I do not own an HD monitor and my monitor does not support anything above 150%/144DPI. Does this mean I can't test for high-resolution situations? Appendix A seems to suggest that anything above 96DPI is high-def, but confusion ensues with Appendix B, which talks about different resolutions of monitors, and my current resolution is nowhere near the ball-park discussed in that section. Wait, so does physical resolution change according to DPI? Ow wait, it must, because that's what it stands for, right? Dots per inch.

• Writing a DPI–aware application is the key to making a UI look consistent across a wide variety of DPI display settings. An application that is not DPI–aware but is running on a high DPI display or across monitors of different DPIs will be scaled by the system to the appropriate size so that it is still usable, but can suffer from visual artifacts including incorrect scaling of UI elements, clipped text, and blurriness. By adding support in your application for DPI awareness level, you can present your application’s UI in a predictable manner. By updating your app to respond to dynamic changes in DPI, you create an application that is crisp, making it more visually appealing to users.

  This tells me that:
  • What I've got now is satisfactory, but only for standard-def displays?
  • This page seems to be oriented around dynamic DPI-awareness: I'm fearing that it is also discussing additional, confusing stuff which I do not actually need to know in order to incorporate basic DPI-awareness.
  • I will not be able to see "incorrect scaling of UI elements, clipped text, and blurriness" because I don't have an HD-monitor? I see this when I dynamically change the setting, but once I sigh-out and in again, everything is fine!
• Looking at the issues in Appendix C, I think I might be falling under the following category (though I'm not 100% sure):

  Incorrect Use of Effective Resolution
  Applications often require a minimum display resolution to run. For example, suppose an application has a minimum required resolution of 1024x720. At run time, the application queries the system to determine the current screen resolution. If the application determines that the screen resolution is less than the required minimum, it prompts the user with a warning.
  Because high DPI settings cause the system to use larger fonts and larger UI elements, it also means that applications take up more pixels when they draw. The result is a lower effective resolution because more pixels are required to render the same UI. The formula to calculate the effective resolution is: Effective Resolution = Physical Resolution / (DPI/96).
  For example, suppose the user has a display of 1200x900 with 144 DPI. The effective resolution of this device is only 800x600 because 144/96 = 150%, which reduces the effective screen real-estate by 50%. This calculation means that the size of the UI and text at this setting is roughly the same as if the user were running at 96 DPI with an 800x600 screen resolution.

  Why I think this is because: my font size in the debug program doesn't change at all. I don't do this. However, it LOOKS fine and isn't blurry. So what I really have to do is scale child windows and fonts? And what does the "effective resolution" mean? I know that it represents the real resolution according to how much your program can take due to the DPI change, but what can I DO with it? How do I get from effective resolution to actual size of my controls, or fonts? Is it like a scaling factor, 'cause that's how I've been treating it for a while, but it seems like it does nothing?

*takes deep breath*

Windows Vista introduced a feature called DPI virtualization, which provides a level of automatic scaling support to applications that are not DPI–aware. With this feature, Windows scales the size of the text and UI elements of applications that are not DPI-aware so that they are appropriately sized on high DPI settings without changes in the application. This prevents potential usability and readability issues that occur when applications render too small on high DPI screens.

So, what's really happening is that my application is running under a virtual DPI. Everything looks the same as if it were running on 100%. But that has issues? They mean. these issues?




They're pretty similar if you ask me. There are differences, but I only noticed them once we zoomed in loads. Surely on such a large screen, nobody's gonna notice stuff like that?

Should I be expecting things to appear the same size everywhere, or should I be scaling everything to really high values?

I am at a loss.

[MrSwiss]

@datwill310,

before reading this, just for the moment, forget everything you've read
on MSDN. Makes it easier to understand the following.

Just a try, to shed some light on DPI scaling stuff: (short and sweet)

• imagine a VGA screen: 640 x 480 pixels
  also think of a 8 x 16 pixels Font (8 = width / 16 = height, in pixels)
  this then results in: 80 characters by 30 lines

VGA screen filled up.
Now we'll try to display that on a HD screen: 1920 x 1080 pixels
It'll look tiny in the center of the display ...

Now assume DPI scaling of 150%: (if all screen elements scale equally)

• Window size (inside) is now: 960 x 720
  Font size is now: 12 x 24
  (this then results in: 80 characters by 30 lines) still the same!!!

This looks a lot more readable ...

The problem is, in reality with FB: the Window itself scales as expected but,
all the components inside (Fonts, GFX shapes etc.) don't scale at all. So you
are getting a Window, with everything inside bunched up at left/top of it ...

With DPI awareness of the whole program, everything would have to scale
equally! e.g. the Font used, needed to be defined at: given-size * 150%
(MSDN assumes, that you're using WIN-API procedures only, this then accounts
for the differences encountered.)

[datwill310]

@datwill310,

before reading this, just for the moment, forget everything you've read
on MSDN. Makes it easier to understand the following.

Just a try, to shed some light on DPI scaling stuff: (short and sweet)

• imagine a VGA screen: 640 x 480 pixels
  also think of a 8 x 16 pixels Font (8 = width / 16 = height, in pixels)
  this then results in: 80 characters by 30 lines

VGA screen filled up.
Now we'll try to display that on a HD screen: 1920 x 1080 pixels
It'll look tiny in the center of the display ...

Now assume DPI scaling of 150%: (if all screen elements scale equally)

• Window size (inside) is now: 960 x 720
  Font size is now: 12 x 24
  (this then results in: 80 characters by 30 lines) still the same!!!

This looks a lot more readable ...

The problem is, in reality with FB: the Window itself scales as expected but,
all the components inside (Fonts, GFX shapes etc.) don't scale at all. So you
are getting a Window, with everything inside bunched up at left/top of it ...

With DPI awareness of the whole program, everything would scale equally!
(MSDN assumes, that you're using WIN-API procedures only, this then accounts
for the differences encountered.)

Thanks for your reply!

Just to clarify: I should be scaling the fonts and the control dimensions by the scaling factor, defined by the DPI scaling, eg increase by 50% for 150%. I would also require to scale parent windows, since the container of the scaled items also needs to be scaled.

This should make the items appear larger, but that's the point, since there are different amounts of pixels displayed on different screens.

What I'm doing seems to work, only because I'm using such small DPI scales and thus everything can still be read. But if I were to do the same on a much larger DPI scale, the output would be almost unreadable, because nothing is actually scaled and the same sizes occupy a much smaller portion of the screen.

Yeah, this makes sense now.

Thanks to all of you for your help! I will incorporate awareness soon.

[MrSwiss]

Just to clarify: I should be scaling the fonts and the control dimensions by the scaling factor, defined by the DPI scaling, eg increase by 50% for 150%.

Yes, that's it. I'd use a multiplier factor, e.g. 1.5 (instead of + 50%) for ease of use, as well as for speed.

I would also require to scale parent windows, since the container of the scaled items also needs to be scaled

This depends on the container type (probably not needed, if it's any Win-API stuff, e.g. a Window) ...

[datwill310]

Just to clarify: I should be scaling the fonts and the control dimensions by the scaling factor, defined by the DPI scaling, eg increase by 50% for 150%.

Yes, that's it. I'd use a multiplier factor, e.g. 1.5 (instead of + 50%) for ease of use, as well as for speed.

I would also require to scale parent windows, since the container of the scaled items also needs to be scaled

This depends on the container type (probably not needed, if it's any Win-API stuff, e.g. a Window) ...

Will do and thanks. It's a normal window, so I shouldn't need to.

[datwill310]

No more procrastination! I'm going to do this!

So OK, the first test seemed to work fine. My fonts and controls scaled appropriately, but my parent window didn't. I'm using the multiplier:

x-coordinate *= (primary monitor's DPI/96)
also for y-coordinates, widths and heights of all controls and fonts, except for the parent window:

I would also require to scale parent windows, since the container of the scaled items also needs to be scaled

This depends on the container type (probably not needed, if it's any Win-API stuff, e.g. a Window) ...

One of my concerns is that, as the controls physically grow in size, as do the fonts, the parent window would not be able to contain everything since it stays the same size. This is certainly the case with my current test. Which makes me wonder if I'm doing something wrong.

All I've done so far is add DPI-awareness for the x, y, width, and height parameters of the GUIFONT class, and the child controls in the GUIWIN class. I have not yet done anything to the parent windows, I have however applied DPI-awareness to any child windows that would be created.

I can run the test again in case you are wanting any details, and I can take screenshots to show you what it looks like (wait, am I being naive here? If I took a screenshot, would "before" and "after" look the same/does the system scale the images it takes? Or am I overthinking this?).

[MrSwiss]

There seems to be a misunderstanding about container:

• fbGFX: Window (FB native) [Screen or ScreenRes] (user scaling required)
  Win-API: Window [CreateWindowEx] (no user scaling/OS scaling)

The fbGFX Window also needs to be scaled ...
naturally on x and y axis (depending on DPI setting/scaling).

[datwill310]

There seems to be a misunderstanding about container:

• fbGFX: Window (FB native) [Screen or ScreenRes] (user scaling required)
  Win-API: Window [CreateWindowEx] (no user scaling/OS scaling)

The fbGFX Window also needs to be scaled ...
naturally on x and y axis (depending on DPI setting/scaling).

I'm pretty sure I'm not using fbGFX, I'm using WinAPI. So everytime I use CreateWindowEx, the OS scales everything for me? So I don't have to add DPI-awareness as Windows already scales according to DPI?

[Josep Roca]

> I would also require to scale parent windows, since the container of the scaled items also needs to be scaled

Of course. Windows will ony scale the caption and the borders. You have to scale the client area.

[datwill310]

> I would also require to scale parent windows, since the container of the scaled items also needs to be scaled

Of course. Windows will ony scale the caption and the borders. You have to scale the client area.

That makes sense. Will do.

[dodicat]

There seems to be a misunderstanding about container:

• fbGFX: Window (FB native) [Screen or ScreenRes] (user scaling required)
  Win-API: Window [CreateWindowEx] (no user scaling/OS scaling)

The fbGFX Window also needs to be scaled ...
naturally on x and y axis (depending on DPI setting/scaling).

To scale the fbgfx window, using the windows function MoveWindow() the window must be without a frame.
This wasn't always the case with FreeBASIC, it changed I think about version 1.

Now the whole functuality of MoveWindow() has been lost with Fb. 64 bit.
It no longer works (Win 10 anyway)

(Nothing to do with Object-Oriented GUI Library, just an observation).

Code: Select all

#include "windows.bi"
if sizeof(integer)=8 then
    print "Doesn't work with 64 bit"
    sleep
    end
    end if
dim as integer xres,yres,wdth 'get the desktop dimensions
screeninfo xres,yres
wdth=xres 'remember the width

'shrink down the width/height
screenres xres/10,yres/10,32,,&h08 'no frame 
screeninfo xres,yres  

Dim As Integer I
Screencontrol(2,I)        'getwindowhandle
Dim As Any Ptr Win = Cast(Any Ptr,I)


color ,rgb(100,0,0)
cls
dim as single ratio=yres/xres

circle(xres/2,yres/2),25,rgb(0,0,200),,,,f
draw string (xres/2-20,yres/2), "HELLO"

'scale up the window and contents
for n as long=1 to wdth-xres
   movewindow(Win,0,0,xres+n,yres+ratio*n,1) 
next n
print "Done"
sleep
 

[datwill310]

Hi,
Does this library supports UNICODE ?.

And it doesn't look like the library is High-DPI aware either?

I think I've been able to incorporate High-DPI awareness!

Sorry it's taken so long. It's all been a mish-mash of doing YouTube, my computer braking loads, writing other projects, and loads more.

I'm not going to release it yet, though: I'm going to post my OGL.bi file in a folder marked OGL.BETA. This is because I'm not actually too sure if I'm doing it right or not. If somebody who's knowledgeable about DPI-awareness could help me out with this by testing the header file with one of your programs, I would be grateful.

I'll update my Acknowledgements section once I fully release OGL 2.1 ;D.

Thanks for being patient.

PS: 2.1 will also have a few more "bug" fixes not yet in the file I released in OGL.BETA.

[datwill310]

Version 2.1 is officially released.

Copy of Version Log in doc:

+ The OGL is now High-DPI aware! This means it automatically scales its windows and fonts according to the current DPI setting. However, the program requires the correct manifest in order to do this (see this tutorial). It can even scale according to individual monitors! However, this is NOT dynamic amendment: if you wish this, you will have to program this yourself. It does not respond to user change of DPI setting, but does respond to it if the user signs out/logs off.
+ Added monitor() function: retrieves the handle to the monitor with the 0-based count index: i.e. primary (default) = 0, secondary = 1, etc. Have not been able to test this yet, since I don't have >1 monitor, but it is definitely able to get the primary monitor's handle.
+ Added monitorw() and monitorh() functions. Self-explanatory.
+ Added monitordpix() and monitordpiy() functions. These get the current DPI setting in both the x and y direction. Usually equal.
+ GUIFONT: added h_dpi and w_dpi properties. These scale a font according to DPI settings on a provided monitor.
+ Added x_center, y_center, x_center_set, y_center_set, and center_set functions. These center windows according to its parent or, in the case of the main window (if without a parent), the monitor most of it is on. The set variant functions actually set the window to the found co-ordinates.
+ Added w_client and h_client, which retrieve the dimensions of the main window's client area.
+ Added ctrlindex, cwinindex, and ctrltype properties. They work with the more "low-level" element of the OGL. They search the internal arrays to see if a provided handle is part of the GUIWIN object, and if it is, its control index is returned. This can also be done with child windows (child GUIWIN objects). ctrltype finds the type of control referenced to by a given control index.