[rcore] Screen Size, Render Size, Monitor Size, DPI Scale consistency

[SoloByte]

Issue Description

The following things are what I understand about screen size, monitor size, and render size. I do not know if I am correct at all. My main goal here is to figure out together what each of this numbers should represent independent of the the operating system.

1. Monitor Size should always report the native resolution of the monitor unaffected by any scaling ?
2. The dpi value should always report the dpi scaling of the system irregardless of the window mode. (windowed & fullscreen should report the same dpi value)?
3. The screen size should be the actual size of the window ? Does this mean it should be in native resolution or in scaled resolution? Should a window covering 1/4 of a 4k monitor with a dpi scale of 2 have a Screen Size of 1920x1080 or 960x540?
4. Should the render size always be the screen size x dpi factor? Or should they be the same? (which kinda makes no sense)

Related Issues

• [rcore] Render issue when window is partially move outside of the monitor #3980
• [rcore] Window Mode Overhaul #4147
• [rcore] Fullscreen & Borderless Fullscreen Problems #4145
• [rcore] ToggleFullscreen() not working as expected with HighDPI mode enabled #3972 (comment)
• [rcore][DESKTOP_RGFW] ToggleFullscreen() and ToggleBorderlessWindowed() not working on Linux ? #4140
• [rcore_desktop] Upon entering fullscreen, uses original window size #3929

My findings:

• On Windows the dpi value is always correct. No matter the window mode it always reports the scaling set in the settings. On macOS it reports the correct value except in fullscreen mode were it always reports 1, 1.
• On windows the monitor size always reports the native resolution of the monitor independent of the system scaling. On macOS it DOES NOT behave this way. Most of the times it is the monitor resolution divided by the scaling or it something weird in the fullscreen modes.
• On windows & macOS the high dpi config flag had no impact on anything as far as I can tell. I have tested it without setting it, with setting it before & after init window, and with clearing it before & after init window. If I did something wrong or missed something please correct me.
• On windows the screen & render size are always the same even if there is dpi scaling. On macOS the render size is always multiplied by the dpi value.
• On windows the size of the window always covers the same area with the same size. Example: On a 4k monitor with scaling of 200% a window of the size 1920x1080 covered 1/4 of the screen. On a 4k monitor with scaling of 100% a window if the size 1920x1080 covered 1/4 of the screen as well. In my opinion that dpi scaling makes sense the a 1920x1080 window should cover the entire screen on a 4k monitor with scaling set to 200%.

Windows

Windowed

• Screen Size: 800x800
• Render Size: 800x800
• Monitor Size: 3840x2160
• DPI: 2,2

Maximized

• Screen Size: 3840x2019
• Render Size: 3840x2019
• Monitor Size: 3840x2160
• DPI: 2,2

Borderless Fullscreen

• Screen Size: 3840x2160
• Render Size: 3840x2160
• Monitor Size: 3840x2160
• DPI: 2,2

Fullscreen

• Screen Size: 3840x2119 !!!
• Render Size: 3840x2160
• Monitor Size: 3840x2160
• DPI: 2,2

MacOS

Windowed

• Screen Size: 800x800
• Render Size: 1600x1600
• Monitor Size: 1920x1080
• DPI: 2,2

Maximized

• Screen Size: 1920x1027
• Render Size: 3840x2054
• Monitor Size: 1920x1080
• DPI: 2,2

Borderless Fullscreen

• Screen Size: 1920x1080
• Render Size: 3840x2160
• Monitor Size: 1920x1080 ?!
• DPI: 2,2

Fullscreen

• Screen Size: 1920x1027 ?! (could be resizable flag)
• Render Size: 1920x1080
• Monitor Size: 1920x1080
• DPI: 1,1 ?!

Monitor Size is always 1920x1080 irregardless of the dpi value (on a 4k screen with system setting resolution set to 1920x1080)

Linux

Can not test it.

Examples

To me personally only Example A makes sense. (on all operating systems. I do not know how scaling works on windows but on macOS it can only be 1, 1 or 2, 2. There are other combinations possible as well not just the ones from example A & B but I didn’t want to write them all down ;)

Example A

• 4k monitor

• Scaling Factor 200%

  • Windowed Mode

    • Screen Size 960x540 (covers 1/4 of the screen)
    • Render Size 1920x1080
    • Monitor Size 3840x2160
    • DPI 2, 2

  • Fullscreen Mode

    • Screen Size 1920x1080 (covers entire screen because it is fullscreen)
    • Render Size 3840x2160
    • Monitor Size 3840x2160
    • DPI 2, 2

• Scaling Factor 100%

  • Windowed Mode
    • Screen Size 1920x1080 (covers 1/4 of the screen)
    • Render Size 3840x2160
    • Monitor Size 3840x2160
    • DPI 2, 2
  • Fullscreen Mode
    • Screen Size 3840x2160 (covers entire screen because it is fullscreen)
    • Render Size 3840x2160
    • Monitor Size 3840x2160
    • DPI 2, 2

Example B

• 4k monitor

• Scaling Factor 200%

  • Windowed Mode

    • Screen Size 1920x1080 (covers 1/4 of the screen)
    • Render Size 1920x1080
    • Monitor Size 3840x2160
    • DPI 2, 2

  • Fullscreen Mode

    • Screen Size 3840x2160 (covers entire screen because it is fullscreen)
    • Render Size 3840x2160
    • Monitor Size 3840x2160
    • DPI 2, 2

• Scaling Factor 100%

  • Windowed Mode
    • Screen Size 1920x1080 (covers 1/4 of the screen)
    • Render Size 3840x2160
    • Monitor Size 3840x2160
    • DPI 2, 2
  • Fullscreen Mode
    • Screen Size 3840x2160 (covers entire screen because it is fullscreen)
    • Render Size 3840x2160
    • Monitor Size 3840x2160
    • DPI 2, 2

[raysan5]

@SoloByte Thanks again for the detailed report and the review of this improvement! It seems there are many issues involved, quite overwhelming...

[SoloByte]

I stiil can not wrap my head around half of the windowing stuff ;) I just wanted to put the information out so there is something to go by.

The window overhaul or maybe even #4151 PR will fix all of that and I can just close this issue 👍 ( In my dreams xD )

[raysan5]

@SoloByte All windowing/display/screen logic has been a pain for years, with multiple reviews and redesigns, last one I did was when window-config flags were added, I think it was for 4.5. There were also some reviews for 5.0 with the platform-split...

This seems to be the new big redesign but the truth is that it is a bit scary; in my experience, there are so many possible scenarios (display, monitor, fullscreen, windowed, highDPI, 4K, multimonitor...) that finding a solution working on all them (and cross-platform) seems a extremely complex puzzle to solve. Not to mention the potential maintenance work.

Still, let's see what comes out!

[SoloByte]

@raysan5

in my experience, there are so many possible scenarios (display, monitor, fullscreen, windowed, highDPI, 4K, multimonitor...) that finding a solution working on all them (and cross-platform) seems a extremely complex puzzle to solve.

I absolutely agree! To me it feels like a 4 dimensional rubiks cube ^^

---

My main problem is that the windowing system is so fundamental to any application that it not working correctly is really hard to deal with. I am not even talking about any special cases but for example that fullscreen is not working or working differently on all the platforms makes it really difficult.

---

One big decision to think about is if raylib should open up certain functionalities so the user can implement them. Right now raylib tries to take care of everything in the windowing system and tries to solve all the problems for all the different setups which might be almost impossible to achieve. This approach is really nice if it works but if it doesn't the user has no real way to deal with it on their end...

For instance if raylib has certain functions in the core class that are used to keep the internals of raylib working (like SetupFramebuffer(), SetViewport(), etc.) and raylib just provides a wrapper around certain backends like GLFW, the windowing & input system could be outsourced. Of course I do not know enough about raylib if this is even possible at all but it might be something to think about.

---

Anyway we will keep working on the window system and see what happens :)