[core] FLAG_WINDOW_RESIZABLE has no effect on PLATFORM_WEB

[Peter0x44]

Issue description

FLAG_WINDOW_RESIZABLE has no effect on PLATFORM_WEB

Issue Screenshot

Code Example

#include "raylib.h"

#ifdef __EMSCRIPTEN__
    #include <emscripten/emscripten.h>
#endif

const int screenWidth = 800;
const int screenHeight = 450;

void UpdateDrawFrame(void);


int main(void)
{
    SetConfigFlags(FLAG_WINDOW_RESIZABLE);
    InitWindow(screenWidth, screenHeight, "web resizing example");

#ifdef __EMSCRIPTEN__
    emscripten_set_main_loop(UpdateDrawFrame, 0, 1);
#else
    SetTargetFPS(60);

    while (!WindowShouldClose())
    {
        UpdateDrawFrame();
    }
#endif

    CloseWindow();

    return 0;
}

void UpdateDrawFrame(void)
{
    static Vector2 ballPosition = (Vector2) { screenWidth/2.0f, screenHeight/2.0f };
    static Vector2 ballSpeed = (Vector2) { 6.0f, 4.0f };
    const float ballRadius = 10.0f;

    ballPosition.x += ballSpeed.x;
    ballPosition.y += ballSpeed.y;

    if (((ballPosition.x + ballRadius) > GetScreenWidth()) || ((ballPosition.x - ballRadius) < 0)) ballSpeed.x *= -1.0f;
    if (((ballPosition.y + ballRadius) > GetScreenHeight()) || ((ballPosition.y - ballRadius) < 0)) ballSpeed.y *= -1.0f;

    BeginDrawing();

        ClearBackground(GREEN);

        DrawCircleV(ballPosition, ballRadius, RED);

    EndDrawing();
}

compile with:
emcc resize_example.c -I path/to/raylib/src ./libraylib.a -s USE_GLFW=3 -s WASM=1 --shell-file minshell.html -o resize_example.html

The following 3 lines seem to do nothing:

raylib/src/rcore.c

Lines 6176 to 6178 in db55bed

	int width = GetCanvasWidth();
	int height = GetCanvasHeight();
	emscripten_set_canvas_element_size("#canvas",width,height);

They set the height of the canvas... to the existing height/width of the canvas, so they are unchanged
The callback they are in is unused, anyway

the following patch seems to fix the issue:

diff --git a/src/rcore.c b/src/rcore.c
index 45495bb1..5b29a5bf 100644
--- a/src/rcore.c
+++ b/src/rcore.c
@@ -925,9 +925,9 @@ void InitWindow(int width, int height, const char *title)
     // Check fullscreen change events(note this is done on the window since most browsers don't support this on #canvas)
     //emscripten_set_fullscreenchange_callback(EMSCRIPTEN_EVENT_TARGET_WINDOW, NULL, 1, EmscriptenResizeCallback);
     // Check Resize event (note this is done on the window since most browsers don't support this on #canvas)
-    //emscripten_set_resize_callback(EMSCRIPTEN_EVENT_TARGET_WINDOW, NULL, 1, EmscriptenResizeCallback);
+    emscripten_set_resize_callback(EMSCRIPTEN_EVENT_TARGET_WINDOW, NULL, 1, EmscriptenResizeCallback);
     // Trigger this once to get initial window sizing
-    //EmscriptenResizeCallback(EMSCRIPTEN_EVENT_RESIZE, NULL, NULL);
+    EmscriptenResizeCallback(EMSCRIPTEN_EVENT_RESIZE, NULL, NULL);
 
     // Support keyboard events -> Not used, GLFW.JS takes care of that
     //emscripten_set_keypress_callback("#canvas", NULL, 1, EmscriptenKeyboardCallback);
@@ -6042,8 +6042,8 @@ static EM_BOOL EmscriptenResizeCallback(int eventType, const EmscriptenUiEvent *
 
     // This event is called whenever the window changes sizes,
     // so the size of the canvas object is explicitly retrieved below
-    int width = GetCanvasWidth();
-    int height = GetCanvasHeight();
+    int width = event->windowInnerWidth;
+    int height = event->windowInnerHeight;
     emscripten_set_canvas_element_size("#canvas",width,height);
 
     SetupViewport(width, height);    // Reset viewport and projection matrix for new size

It uncomments the lines that set the callback, and sets the canvas width/height to the windowInnerWidth and windowInnerHeight

The result:

resizer.mp4

[raysan5]

@Peter0x44 Sincerely, I can't remember why that code was there and what problem it tried to solve... but feel free to send a PR with the proposed changes.

[RadsammyT]

Was kinda curious of the backstory and did some digging into this so heres a quick gist. The 3 lines that set the canvas dimensions to itself was introduced with PR #1840 which introduced/finished up emscripten canvas resizing. To my knowledge, the foundation of this hasn't been changed since (aside from the occasional commenting and tweaking).

A while after this, raysan commented the most of the code out for review (see 8f2d983) as games and examples would somewhat break when going into fullscreen, which should be where we are right now.

[Peter0x44]

I tried with my proposed patch, and didn't notice any issue upon going into fullscreen
Should I just submit it as a PR, then?

[RadsammyT]

And just to make sure, you didn't notice any issue when pressing Fullscreen in src/shell.html?
If no issues were found even from the shell then it should be fine to submit it as a PR.

[raysan5]

didn't notice any issue when pressing Fullscreen in src/shell.html?

@Peter0x44 did you try this case?

[raysan5]

@Peter0x44 tested the proposed change and it breaks the full-screen option, that was the reason it was commented. The issue should be fixed/reviewed in some other way but I remember it was not an easy topic, many side-cases and possibilities.

[raysan5]

@ubkp Please note that this issue could be very tricky, I remember dealing with it in the past and not being able to find a proper solution. The point is that window resizing vs scaling is application-dependant. For example:

• Game application: You want the canvas to be properly scaled (maintaining aspect-ratio) to the browser window.
• Tool application: If tool supports resizing flag (FLAG_WINDOW_RESIZING), you want the canvas to be expanded with the browser window size, that could not be full browser size but only a part of it (imagine some header div in the browser or footer).

Not to mention that fullscreeen switch will also launch the window resizing callback and the expectations for full-screen are completely different, actually there are multiple fullscreen strategies available.

Oh, and just a last detail that I came up recently, the results seen on desktop-browser could completely differ from mobile-browser. That's another added problem to take care...

[ghost]

@raysan5 Thank you very much for the guidance and references. I'll give it a week to see how far I can go. If I don't figure out anything by then, I'll withdraw.

[raysan5]

@ubkp Any update on this issue? If no updates I will close it, I manage resizing as canvas CSS and it works for me.

[Peter0x44]

Could you elaborate on this CSS? I think it would be good reference to others

[raysan5]

@Peter0x44 You can check shell.html behaviour, provided with raylib. It resizes canvas with browser.

EDIT: Here an example: https://www.raylib.com/timeline.html

[Peter0x44]

@raysan5 shell.html doesn't do the same thing (acting like FLAG_WINDOW_RESIZABLE, I think)
You can clearly see in this example the "ball" gets smaller as I resize the browser window, and also it's not "bouncing" from the edges.
I don't believe any existing functionality is covering this, I think this issue should be kept open

shellhtmlexample.mp4

[raysan5]

@Peter0x44 True, you are right, shell.html scales the canvas proportionally to the browser window.

Still, the proposed changes break that behaviour. I'll keep it open for future review.

[ghost]

@raysan5 Really sorry for the late reply. I had a rough week that kept me away.
If you could keep this open for a few more days, I still want to take a crack at it.

[raysan5]

@ubkp Sure, take your time, I'll keep this issue open until a proper solution can be found.

[ghost]

Ok, so, the resize is working, well, kinda.

1. Regarding the resizing itself:

We probably shouldn't use event->windowInner*, because if the program/game is loaded right from the start with FLAG_WINDOW_RESIZABLE enabled, it could (happened to me here) have a zero value until some resize event happen, thus causing the canvas to be 0x0 sized until there.

Luckly this is an easy fix with:

EM_JS(int, GetWindowInnerWidth, (), { return window.innerWidth; });
EM_JS(int, GetWindowInnerHeight, (), { return window.innerHeight; });
[...]
int width = GetWindowInnerWidth();
int height = GetWindowInnerHeight();

The logic being that due to the async nature of emscripten's callbacks, the EM_JS call will happen at least 1 frame after the canvas instantiation.

2. Regarding the resizing behavior:

This resize works on the assumption that (when the user resizes) the user will want the canvas to fill the entire window size. Which could or could not be the case.

IMHO, a Size maxCanvas should, most likely, be introduced to allow the user to have such choice. Probably something along these lines:

#if defined(PLATFORM_WEB)
Size maxCanvas;
#endif
[...]
CORE.Window.maxCanvas.width = ...;
CORE.Window.maxCanvas.height = ...;
[...]
void SetMaxCanvas(int width, int height);

Edit: Case example at #3231 (comment).

3. Regarding the resizing scale:

This resize doesn't change the scale, which, IMHO, is ok, since scaling currently is being left to the user (ref.: #3207 (comment)).

4. Regarding the standard fullscreen:

The default (non-scaling) fullscreen is working. Either by pressing F11 directly on the browser, or by calling something like:

<button onclick="document.getElementById('canvas').requestFullscreen();">Fullscreen</button>

Edit: The F11 will make the entire page fullscreen. It fooled me because resize was making the canvas the same size of the screen. So, F11 is a whole different thing.

5. Regarding the emscripten's fullscreen:

The fullscreen issues appear to be related to the particular way shell.html (L176) calls for fullscreen:

onclick="Module.requestFullscreen(false, false)"

If that requestFullscreen() is this one (test_html5_fullscreen.c#L135):

void requestFullscreen(int scaleMode, int canvasResolutionScaleMode, int filteringMode)

Then flipping the canvasResolutionScaleMode parameter fixes it for this specific use case:

onclick="Module.requestFullscreen(false, true)"

6. Regarding the shell.html scaling issue:

With this resize enabled, when launching the program/game using the default shell.html it will have the wrong scaling. That appears to happen because the canvas.emscripten CSS is setting width: 100% (L79) which is trying to match the new resized size.

Removing width: 100%; fixes it for this specific use case.

7. Regarding leaving emscripten's fullscreen:

If the user starts the program/game, then resizes it, then launches the fullscreen with Module.requestFullscreen, then leaves the fullscreen, the returning resolution won't be the previous resized one, but the initial one (e.g.: 800x450).

This one I couldn't figure out yet, but, by the initial values, I'm assuming that emscripten is storing them somewhere and using it when leaving a fullscreen that started from Module.requestFullscreen.

8. Moving forward:

So, IMHO:

• A. Item 1 is the way to go;
• B. Item 2 could be left to the user, but I think it would be really helpful to have, if you don't mind the extra functions/variables;
• C. Item 3 is the way to go;
• D. Item 4 is what I expect as "default" behavior on web (since the user can, and will, press F11 to go fullscreen and, aside from using custom JS on the shell.html to intercept the F11 keypresses, we can't really, or shouldn't really, stop it);
• E. Item 5 and 6 are mostly collateral from shell.html one-size-fits-all, but shouldn't be a problem for actual library usage;
• F. web fullscreen should be handled by ToggleFullscreen() (L1262) and/or emscripten_set_fullscreenchange_callback() (L933-L939);
• G. Item 7 I'm still trying to figure out.
• H. The fullscreen issues (4, 5) should be handled as a separate issue/feature and shouldn't block adding resizing (1, 2, 3).

@raysan5 Could you please evaluate these?

Edit 1: Changed itens 4 and D.
Edit 2: Added link to case example on item 2.

[Peter0x44]

Thanks for the detailed investigation! It's really summarizing everything nicely

About point 2), I don't think any web-only (or any platform-specific) functions are exposed right now, and I don't think Ray will like that idea.

I don't have a much better one though.
Perhaps adding "SetWindowMaxSize", to compliment "SetWindowMinSize" and then implementing that on desktop too is an option.
Despite that it's probably not very useful outside of web.

[ghost]

@Peter0x44 Consider the case where the browser has a size of 1920x1080 and the program/game screen/canvas has an initial size of 800x450 and FLAG_WINDOW_RESIZABLE enabled. The instant the user starts a resize it would jump from 800x450 to the size of the browser window (e.g. jumps from 800x450 to 1900x950). A max size is really helpful is you want to keep a given size and just allow to resize it down (which is a behavior very prevalent on web structures).

But that would actually be excellent to also have on PLATFORM_DESKTOP too, specially for tools.

[raysan5]

@ubkp Wow! What a detailed review! Give me some time to evaluate it carefully!

[raysan5]

@ubkp Again, a very nice and detailed explanation! I'm still processing everything carefully. In any case, some notes:

Perhaps adding "SetWindowMaxSize", to compliment "SetWindowMinSize" and then implementing that on desktop too is an option.

@Peter0x44 Actually I think this is a good approach and yes, it can be useful outside web for windows that can not be scaled beyond a specific size (personally, I could think of some use cases on my tools). But in any case sounds a fair addition for function consistency.

But that would actually be excellent to also have on PLATFORM_DESKTOP too, specially for tools.

@ubkp Oh, just saw your comment arriving to my same conclusion! 😄

I think the proposed improvements are great. My main concern is probably on shell.html and minshell.html, used by most of my tools and sample games. Maybe they could require some review...

• shell.html: Canvas/screen is scaled with browser but not resized, allowing a full-screen scaled mode.
• minshell.html: Canvas is not scaled neither resized (as expected), F11 keeps the current size, maybe it would be nice to center it on screen and allow a background color. It can be tested with rFXGen here: https://raylibtech.itch.io/rfxgen

In any case, it's a really good improvement, I think some of my tools (rTexViewer, rTexPacker) could really benefit of a true resizing option on the browser!

[ghost]

I think the proposed improvements are great. My main concern is probably on shell.html and minshell.html, used by most of my tools and sample games. Maybe they could require some review...

AFAIK, minshell.html, as is right now, works well with FLAG_WINDOW_RESIZABLE with the caveat that, without some SetWindowMaxSize, it will resize to the full window size.

But shell.html, containing width: 100%, will always present scaling issues if FLAG_WINDOW_RESIZABLE is enabled, to no fault of EmscriptenResizeCallback(), but because shell.html it's applying a modifier the program/game can't predict.

I think the easiest solution would be that the developer just not enable FLAG_WINDOW_RESIZABLE on the web version of his program/game if he chooses to use the default shell.html even more so because, in that case, the width: 100% is already doing the resizing for him automatically.

[raysan5]

@ubkp Is it possible to allow in any way the width: 100% for automatic screen scaling to browser side from user side? (instead of appying it in shell.html).

In any case, you can send a PR with the proposed improvements, undoubtely is the way to go... Despite having the browser automatically manage the scaling is really confortable in some situations...

[ghost]

@raysan5 Yes, I believe the easiest way would be:

EM_ASM( { document.getElementById("canvas").style.width = "100%"; } );

Full example (tested successfully here):

#include "raylib.h"

#if defined(PLATFORM_WEB)
#include <emscripten/emscripten.h>
#endif

int main(void) {

#if defined(PLATFORM_WEB)
    EM_ASM( { document.getElementById("canvas").style.width = "100%"; } );
#endif

    InitWindow(800, 450, "test");
    SetTargetFPS(60);
    while (!WindowShouldClose()) {
        BeginDrawing();
        ClearBackground(RAYWHITE);
        DrawText("Test", 20, 20, 20, BLACK);
        EndDrawing();
    }
    CloseWindow();
    return 0;
}

However, if you would like to keep shell.html as is (with width: 100%) I think that would be totally fine. It's just a matter of remembering to not enable FLAG_WINDOW_RESIZABLE for web when using shell.html because width: 100% would already be handling resizing.

But, on the other hand, removing width: 100% would probably help make the shells more standard and easier to debug.

@Peter0x44 Since you found the solution, would you like to send the PR? I can implement the SetWindowMaxSize() after that.

[Peter0x44]

So, my initial patch is okay?
What about this comment:

We probably shouldn't use event->windowInner*, because...
I'm not entirely sure what you actually want me to submit

[ghost]

Yes, your initial patch (#3231 (comment)).

Just replace (on L6168-L6169):

EM_JS(int, GetCanvasWidth, (), { return canvas.clientWidth; });
EM_JS(int, GetCanvasHeight, (), { return canvas.clientHeight; });

By:

EM_JS(int, GetWindowInnerWidth, (), { return window.innerWidth; });
EM_JS(int, GetWindowInnerHeight, (), { return window.innerHeight; });

And, on your patch, instead of:

int width = event->windowInnerWidth;
int height = event->windowInnerHeight;

Please use:

int width = GetWindowInnerWidth();
int height = GetWindowInnerHeight();

Which addresses that item 1 from #3231 (comment).

[Peter0x44]

Submitted. Please give an "LGTM" so I know I haven't missed anything.

[Peter0x44]

No, this is not okay. I closed the PR, it doesn't work as expected.

[ghost]

@Peter0x44 Just tested your PR sucessfully on PLATFORM_WEB with Firefox (115.1.0esr 64-bit) and Chrome (115.0.5790.170 64-bit) both running on Linux Mint (21.1 64-bit).

What issue did you encounter?

[Peter0x44]

issueexample-2023-09-11_02.34.10.mp4

I suspect something about the calculated size is incorrect. There is a some blank space at the bottom of the page, with minshell.html. Maybe it's the problem, I don't know.

this is with firefox 117.0, on linux x11.

[Peter0x44]

I just realized this was actually an issue previously - I just didn't notice, since I had a white background.
Maybe the PR is still correct. Ray should feel free to reopen and merge it, but I'd rather not have it be my responsibility anymore if it's breaking something.

[Peter0x44]

Okay, it seems it is the fault of minshell.html. Removing the <p id="output" /> tag does make the "white space" smaller, but doesn't remove it entirely. I'm confident enough the change isn't the problem. Reopened.

[ghost]

@Peter0x44 The PR was fine, that "bottom white background" is just the <p id="output" /> from minshell.html#L59 that's taking up some space from being a block level element. If you comment it you'll see just a thin white line.

[Peter0x44]

Is there any way to eliminate the thin white line entirely?

[ghost]

@Peter0x44 Sure, just add overflow: hidden; to the body CSS (minshell.html#L34). The scrollbars are causing that.

[Peter0x44]

Thanks! I'm not much of a web dev so the solution wasn't obvious to me.

[raysan5]

Reopening because some of the proposed functionality has not been implemented yet.

Waiting for SetWindowMaxSize(), @ubkp

[ghost]

@raysan5 I'm on it. I should have a PR ready fairly soon. 👍

By the way (just in case it got missed in the noise), the answer for you previous question: #3231 (comment)

[raysan5]

By the way (just in case it got missed in the noise), the answer for you previous question: #3231 (comment)

@ubkp thanks for the info, yeah, that could be a good solution. I still have to do some tests with my apps to see what works best.

[raysan5]

Tested and working as expected! Thanks!