Display resolution/scaling and window size problems

[rserban]

Describe the bug
The window size does not seem to respect display scaling settings (Linux Ubuntu 22.04.5)

To Reproduce

1. Set window size (WindowTraits::width and WindowTraits::height) to match display resolution (2880x1800 in my case).
   (I used the vsgwindow example here and modified the size of the second window it creates)

2. Set display scale to 100% and run example. The window will fill the screen (as expected).

3. Set display scale to 150% and run example. The window will be smaller than the screen size.

Expected behavior
In step 3 above, I expected the window size to be larger than the actual screen. Instead, I get the results shown in the screenshot below.

Note that the same experiment on Windows 11 (23H2) gives the expected results.

Screenshot

Comments
Here's the output from xandr -q:

radu@zephyrus:~$ xrandr -q

Screen 0: minimum 320 x 200, current 3840 x 2400, maximum 16384 x 16384
eDP-1 connected primary 3840x2400+0+0 (normal left inverted right x axis y axis) 302mm x 189mm
   2880x1800     60.00*+ 120.00 +  96.00    72.00    60.00    50.01    48.00  
   1920x1200    120.00  
   1920x1080    120.00  
   1600x1200    120.00  
   1680x1050    120.00  
   1280x1024    120.00  
   1440x900     120.00  
   1280x800     120.00  
   1280x720     120.00  
   1024x768     120.00  
   800x600      120.00  
   640x480      120.00  

The screenshot I attached above suggests that the window size is based off the current values for the virtual screen (3840x2400) and ignores the actual display resolution and scaling.

Additional context
In case this was addressed in more recent commits, here are the versions I'm using:

• vsg: Tag v1.1.4
• vsgXchange: Tag v1.1.2
• vsgImGui: latest
• vsgExamples: Tag v1.1.4
• assimp: Tag v5.3.1

[robertosfield]

What window manager are you using?

What command line parameters are you using?

I have just tried Kubuntu 24.04 with 'vsgviewer models/teapot.vsgt --fs' and 'vsgviewer models/teapot.vsgt -w 1280 1024' and it works as fullscreen and relative to actual window size when changing the KDE Global Scale between 100% and 200%.

FYI, the vsg::Xcb_Window that does the Windowing under Linux isn't aware of the window manage scaling, it just creates a window of a WindowTraits defined size using Xcb, it doesn't attempt to query what the window manager might be doing.

[rserban]

I'm running Mutter as WM (and Gnome 41.7 for DE).

I was not using any command line arguments other then the model (I had simply modified the vsgwindows example to hardcode the size of the 2nd window it opens to match my display resolution).

I tried vsgviewer like you did. Setting it in full screen mode (vsgviewer teapot..vsgt --fs) works fine, regardless of the current display scale setting. But vsgviewer teapot.vsgt -w 2880 1800 behaves exactly as I described above.

While changing the window size can deal with very small windows (although I would have preferred to be able to have a default setting for our own demos that work across platforms), that does nothing for things like size of text in ImGui.

[robertosfield]

Window managers can ignore settings we try to use or add in behaviours that a lower level API knows nothing about. When implementing Xcb-Window I did see any scaling functionality. In X11 there is an override redirect option that disabled this via WindowTriats. But you also loose the window decoration doing this. Qt has it's own window scaling that the vsgQt honours so you try it.

…

On Wed, 13 Nov 2024, 13:31 Radu Serban, ***@***.***> wrote: I'm running Mutter as WM (and Gnome 41.7 for DE). I was not using any command line arguments other then the model (I had simply modified the vsgwindows example to hardcode the size of the 2nd window it opens to match my display resolution). I tried vsgviewer like you did. Setting it in full screen mode (vsgviewer teapot..vsgt --fs) works fine, regardless of the current display scale setting. But vsgviewer teapot.vsgt -w 2880 1800 behaves exactly as I described above. While changing the window size can deal with very small windows (although I would have preferred to be able to have a default setting for our own demos that work across platforms), that does nothing for things like size of text in ImGui. — Reply to this email directly, view it on GitHub <#1328 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKEGUGYLNFAZNWOGJ7Y4FT2ANIDLAVCNFSM6AAAAABRWE4OHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZTGYZTCNRRHA> . You are receiving this because you commented.Message ID: ***@***.***>

[AnyOldName3]

X11 doesn't support fractional scaling at all (although some people use forks that mostly work when applications are aware they're running on those forks). In Ubuntu 22.04, which doesn't use Wayland by default, fractional scaling is done by drawing everything at the next integer scale, and then scaling it back down again, so everything ends up blurry, but applications only need to support integer scale factors (or be entirely unaware of scaling and let the window manager multiply all the sizes it's given). If I had to guess, I'd say that maybe we're using functions that always work in physical pixels instead of virtual pixels, which gives us the responsibility to handle scaling ourselves, which we don't. Even if we did, it would probably end badly as the only portable display scale factor (i.e. the one that doesn't tie the VSG to a fork of X11) is the integer one, which still wouldn't do what we want.

This problem isn't going to go away until the VSG has native support for Wayland, and then it'll only be gone on distros using Wayland by default. The latest versions of most big distros now default to Wayland, so that's an increasingly minor concern, but it's not ubiquitous yet.