[rcore][GLFW] REVIEWED: SetWindowSize(), scaling issues on Retina display

[JoeStrout]

I ran into the following issue (on MacOS):

1. On app startup, I call SetWindowSize 800,600. I then enter my usual drawing loop.
2. If I launch this on the external display, it works fine. But if I launch it on the Retina display, it's blank. Even if my drawing loop is nothing but ClearBackground and DrawFPS (between Begin/EndDrawing of course), all I see is the background color — no FPS.
3. If I drag the window over to my external monitor, suddenly I see all the content (FPS and any other drawing).
4. If I then drag it back to the retina display, I still see the correct content.

The issue seemed to be that SetWindowSize updated CORE.Window.screen but not CORE.Window.render (and moving the window to another display caused the render to update, thus "fixing" the issue).

This PR adds code to update the render right away. Now my resized windows correctly show their rendering, even on a retina display. Tested both with and without the FLAG_WINDOW_HIDPI flag.

[JoeStrout]

NOTE: the actual fix was coded by Claude Opus 4.6.

[raysan5]

@JoeStrout Note that GLFW manages multiple platforms, did you test those changes on Windows, Linux X11, Linux Wayland and HTML5? Did you test those changes on multiple monitors configuration with different DPIs?

[casperbear]

Tested on Windows 7 with below scenario. No regression.

        if ((IsKeyDown(KEY_LEFT_ALT) || IsKeyDown(KEY_RIGHT_ALT)) && (IsKeyPressed(KEY_ENTER) || IsKeyPressed(KEY_KP_ENTER)))
        {
            if (IsWindowFullscreen())
            {
                ToggleFullscreen();
                G.screenWidth = SCREEN_WIDTH;
                G.screenHeight = WINDOWED_SCREEN_HEIGHT;
                SetWindowSize(G.screenWidth, G.screenHeight);
            }
            else
            {
                G.screenWidth = SCREEN_WIDTH;
                G.screenHeight = FULL_SCREEN_HEIGHT;
                SetWindowSize(G.screenWidth, G.screenHeight);
                ToggleFullscreen();
            }
        }

[JoeStrout]

I don't have the hardware (or VM setup) to test on anything other than Mac. But on Mac, I did test with multiple monitors with different DPIs.

[maiconpintoabreu]

Hi there, tested it on Debian INFO: PLATFORM: DESKTOP (GLFW - X11): Initialized successfully and No regression. (No impact for Linux with or without the fix)

[raysan5]

As expected with this kind of sensible changes, it breaks windows scaling on Windows. Tested on Windows 10.

The mouse position is offseted.

[JoeStrout]

I now think the fix is incomplete. With this fix, my drawing appears, which is an improvement (before, the window remained stubbornly blank). But everything appears twice as big (and far from the origin) as it should, and I'm so far unable to fix this by adjusting the zoom via BeginMode2D.

I'm hampered by poor understanding of how Raylib is supposed to work on a HDPI window. In the absence of camera shenanigans, are all drawing and mouse coordinates supposed to be in (high-density) pixels, or (72dpi-ish) logical points?

[JoeStrout]

More clues: here's a program running first on a regular (non-HDPI) monitor, with code to draw a 100-pixel grid and label the lines with X and Y values:

...and the exact same program running on an HDPI display (with FLAG_WINDOW_HIGHDPI in effect, and the fix in this PR):

Everything's twice as big as I would expect, and it is offset -- the top of the window is now at y=300 (exactly half of the 600-pixel height I specified in SetWindowSize).

It's scaled up from the bottom, or for some other reason offset by half the height. The DrawFPS output is no longer visible, because it's way off the top of the window. And the other weird things I saw with my real code earlier make more sense now; when I zoom < 2.0, it's shrinking the display up towards a corner 300 points off the top of the window.

So now I think I probably could work around this with sufficiently clever use of BeginMode2D, but I doubt that this behavior is intended. It's weird that in HDPI, all drawing is 2X larger; if anything I'd expect it to be 2X smaller. Probably there is code in there meant to compensate for that, and it's somehow being applied twice.

[JoeStrout]

It appears that the real problem was just an error on my end; I failed to call SetConfigFlags(FLAG_WINDOW_HIGHDPI); before InitWindow. Once I do that, everything appears to work as intended.

I'm closing this PR, and I apologize for wasting everyone's time. I'll be more thorough next time I think I've found a bug!