Implement changes for 3372

[ypujante]

After digging more into the code, (again thanks to the fact that the code is now split so it is easier to make changes without worrying that will break all the other platforms), I think I am actually able to implement the changes directly in raylib, thus not relying on the changes in emscripten ever being added.

First of all let's start with examples:

• core_window_flags
• core_window_letterbox.html

As you can see now there is a 4k checkbox that lets you toggle between HiDPI and not. I picked these 2 examples because the first one is not resizable, the second one is, so that all cases are covered. I spent a big amount of time making sure that entering and exiting fullscreen works properly. Of course this checkbox has no effect on a non 4k/retina screen and I imagine it would be easy to hide it when the monitor does not support HiDPI.

The idea behind the implementation is that raylib is now more in charge of the width/height and set the framebuffer width/height accordingly. This includes handling fullscreen properly as well. Also I "fixed" the discrepancy issue I mentioned in the other PR.

This is a draft PR, as you can see there is a bunch of trace/logs to follow what is going. There is also no detection of DPI changing (example dragging on another monitor), but this is easy to add.

The only thing that I am not too crazy about is the fact that the compilation command now need to include: -s EXPORTED_FUNCTIONS=_main,_SetHighDPIAware,_FullscreenCallback -s EXPORTED_RUNTIME_METHODS=cwrap because it's C code being invoked from Javascript (see emscripten doc). I can image that this could be alleviated by raylib providing it's own RAYLIB_EMSCRIPT_LINK cmake option. I also did not change the other build methods (make, zig...).

I just want to get your feedback whether you think this is the proper direction to go or you don't feel like it.

[raysan5]

@ypujante I'm reviewing this PR and the amount of changes is considerable, this is quite scary and makes me wonder the percentadge of users that would really benefit of this redesign...

Is it possible to avoid/minimize the addition of new functions? raylib API is common for all platforms, I prefer to avoid exposing platform-specific functions at this moment. If it's easier to wait until Emscripten implements the changes to simplify code on raylib-side, I prefer to follow that route.

EDIT: Please note that those changes try to cover a very specific use case for raylib... I really need to review it carefully considering the case I have to maintain it in the future and the possible issues it could generate.

EDIT2: Another option is completely moving this feature to user side, if possible, to let the users implement it when desired.

[ghost]

I'd vote/advise against this change. Right now PLATFORM_WEB is fairly stable. This is far too much change to address one issue.

[ypujante]

Given the feedback, I am just going to close this. It's probably better to wait until emscripten changes have been merged at which point I might open another PR on raylib.

[raysan5]

@ypujante Please note that I try to balance raylib changes with the maintenance cost, I usually minimize the addition of new functions and I give priority to more general issues than specific ones. I'm really sorry for all the work you put on this improvement, I did not imagine the amount of change and redesign required was that big, sorry.

Still, it can be reviewed and reconsidered when the Emscripten-side improvement gets implemented, if it simplifies the implementation on raylib side, I'm open for another review in that case, I will try to focus more efforts on the implication costs of those additions to avoid that extra work for you.

[tromero]

The work is appreciated, I've integrated this into my own branch and have been using it extensively for iPhone/iPad/Mac high-res webGL in my game.