[rcore] [web] Fix mouse position on resize callback

[ghost]

No description provided.

[zet23t]

I can confirm that this fixes the mouse cursor issue, but the resizing is still breaking the web page: When the SetWindowState(FLAG_WINDOW_RESIZABLE); is set and the canvas is embedded in a web page, upon return from fullscreen mode, the canvas element has a different size and overlaps other elements. I don't know why it behaves this way and why the changes I did (#4734) are handling this switch correctly.

[zet23t]

Here are the files I use to test this pull request:

https://gist.github.com/zet23t/9b98d9f22a20e5c056a374dd4413278b

[zet23t]

Both modes break the original canvas size (or don't restore it properly).

[zet23t]

No. My test case is slightly different as it has a canvas that is integrated on a website. Here is the start situation (resizable true)

And here is what happens when the browser window is resized:

It is not even necessary to go to full screen even. The reason why the testcases on your machine don't show problems is, that upon window size change (either by triggered by fullscreen toggle or window size change), the canvas uses the entire browser's client area. If the canvas is using this size anyway, there's no problem. But when the canvas is part of a website, it breaks due to assigning the canvas the current client size area as new canvas size.

[zet23t]

Well, the changes I did do fix these issues altogether, even though the handling is a bit awkward.

[raysan5]

@asdqwe @zet23t Thank you very much for working on this issue! Please gave me some days to review it properly. I'll try to setup some quick examples to illustrate my use-case.

The specific use case I found the issue with was on some of my tools that allow a RESIZABLE window, the canvas covers all the browser window and the tools gets resized responsively with the canvas. Here it is an example: https://www.raylibtech.com/rtexviewer/

Note the main toolbar gets resized with the browser window. This release works as expected because it was build with a previous library_glfw.js version not including the "HighDPI support improvement". Currently in the mouse is completely off.

On the other side, there are the examples that use CSS to set width: 100%, in that case mouse is scaled accordingly to be reported considering canvas scaling.

Despite it worked as expected before the HighDPI change, I fear new implementation could not work on both cases... or maybe I'm not properly understanding all the parts involved... I need to review it more carefully.

[zet23t]

Honestly, when I tried to fix the issues I've had, it crossed more than once my mind to bypass GLFW bindings and bind directly to JS using emscripten. This 2nd abstraction layer in between makes this quite a black box what is going on. I don't know though how much work that would be. In the approach I chose, I decided to ignore the GLFW mouse input feedback and use emscripten's callback instead. But yeah, this is quite a mess, unfortunately.

[raysan5]

Honestly, when I tried to fix the issues I've had, it crossed more than once my mind to bypass GLFW bindings and bind directly to JS using emscripten. This 2nd abstraction layer in between makes this quite a black box what is going on.

Completely agree! Also considered it several times! Latest update of library_glfw.js gave me lot of dissatisfaction...

Afaik, that's what @ColleagueRiley did for RGFW.h, just using a custom implementation directly.

[ColleagueRiley]

@raysan5 Iirc platform_web already implements a lot of the backend on its own. It would still require some work and would force you to maintain an extra layer of Raylib, but it could be worth it.

Also for RGFW, I'm thinking about dropping Emscripten callbacks in favor of directly calling the JS callbacks just to be less Emscripten dependent. It would also be nice if I could drop the Emscripten from RGFW entirely, but I don't think that's possible, at least not without A LOT of extra work.