[JS Newbie] Best way to resize canvas inside browsers

[Flix]

Hi.

Most of the time I use emscripten just to compile C++ OpenGL programs (using glut, glfw or SDL2), so that they run inside browsers, without much care about the Javascript code in the html shell (well, with a few exceptions).

In any case, I'm noticing that when I click on the fullscreen button (inside the html window in the browser), the resize event I set on my binding (glut, glfw or SDL2) does not seem to get called.

So my simple questions are:

• Is there some common strategy to call the resize event when the user wants to toggle fullscreen mode inside the browser ? (I think this is less trivial than it seems, because, for example, the ESC button that is required by Firefox to exit fullscreen mode is not passed to the C++ button event, as far as I know).
• More generally, is it possible to detect when the user resizes the browser window, and/or to know the size of the initial browser window, so that we can set the initial size based on it?

Thanks in advance for your suggestions!

[Flix]

> I'm noticing that when I click on the fullscreen button (inside the html window in the browser), the resize event I set on my binding (glut, glfw or SDL2) does not seem to get called.

Jus wanted to clarify that the program does go into fullscreen mode, it's just the resolution that looks like the same as before.

[Floh]

The whole topic of fullscreen in emscripten surprisingly complex, mainly because the HTML5 fullscreen API is an over-engineered mess (IMHO).

The emscripten wrapper APIs try to wrap this mess into a sane C API, exposing different fullscreen strategies (things like: should the canvas stretch, or increase its resolution etc, should the 'real' HTML5 Fullscreen mode be used, or a 'soft fullscreen', where the canvas is maximized within the browser window's client area etc...)... it's all described here: https://kripken.github.io/emscripten-site/docs/api_reference/html5.h.html#fullscreen

The main problem with 'real' fullscreen mode is that it cannot be toggled programmatically from the C side, since the the fullscreen activation must happen from a Javascript input event handler which requires some back and forth between the C and JS side (JS input handler code calls C to request fullscreen change, and behind the scene, JS calls a C user callback again when the fullscreen state has changed).

Also last I know Safari on iOS doesn't support this 'true' fullscreen mode.

Some example code (of the C side) is here: https://github.com/floooh/oryol/blob/master/code/Modules/Gfx/private/emsc/emscDisplayMgr.cc

I also wrote a blog post about an 'alternative soft fullscreen' mode which allows to layer HTML+CSS UI elements on top of the WebGL canvas (the standard soft-fullscreen mode will hide all other elements on the page):

http://floooh.github.io/2017/02/22/emsc-html.html

Hope this helps :)

-Floh.

[Jukka Jylänki]

2017-09-05 14:04 GMT+03:00 Floh <flo...@gmail.com>:
> The whole topic of fullscreen in emscripten surprisingly complex, mainly
> because the HTML5 fullscreen API is an over-engineered mess (IMHO).

Floh, this is the first time I hear about this problem. By HTML 5
fullscreen API here, are you referring to the web browser's Fullscreen
request API (https://fullscreen.spec.whatwg.org/), or Emscripten's
HTML5 request API?

> The main problem with 'real' fullscreen mode is that it cannot be toggled
> programmatically from the C side, since the the fullscreen activation must
> happen from a Javascript input event handler which requires some back and
> forth between the C and JS side (JS input handler code calls C to request
> fullscreen change, and behind the scene, JS calls a C user callback again
> when the fullscreen state has changed).

This is not accurate. Real fullscreen mode can be toggled
programmatically in C code, but like you mention, due to browser
security restrictions it must happen inside an event handler. This
restriction does not however mean that there is any need for any back
and forth between C and JS code, but it is possible to register an
event handler using the C API, and perform the request in C code in
that event handler, so juggling between C and JS is not fundamentally
necessary to work around this security restriction.

It is naturally required for one to refactor the application to
perform the fullscreen requests in event handlers, but the point is
that this is orthogonal to C vs JS language programming
considerations.

> Also last I know Safari on iOS doesn't support this 'true' fullscreen mode.
>
> Some example code (of the C side) is here:
> https://github.com/floooh/oryol/blob/master/code/Modules/Gfx/private/emsc/emscDisplayMgr.cc
>
> I also wrote a blog post about an 'alternative soft fullscreen' mode which
> allows to layer HTML+CSS UI elements on top of the WebGL canvas (the
> standard soft-fullscreen mode will hide all other elements on the page):

Based on this article, I can only find one limitation of Emscripten's
HTML5 API, that it does not allow customizing this show/hide behavior
in soft fullscreen mode. Is the lack of this customization feature why
you mention the HTML5 fullscreen API being an over engineered mess?

[Floh]

Ah sorry, I should have been more clear, I'm complaining about the WHATWG Fullscreen API, *not* the emscripten API (which actually is a sane wrapper around the underlying mess).

Ok, rant time:

I think this is one of those cases where worst-case-scenario requirements (protect user from fishing attempts) led to an API which for the default-scenario is an annoyance both for the developer and the user. The pointerlock-API has the same problem, but is even worse. I sort of get the intent, but at some point somebody should either have said "guys what we do here is bullshit, let's go back to the drawing board", or alternatively somebody should have kicked the over-paranoid security-guys out the door (IMHO security should happen *under the hood*, it should ideally not deteriorate the developer-experience, and especially not the user-experience).

Annoyances of the Fullscreen API:

- Must be initiated from input event handler, this basically means a game needs some sort of start button. But the point of running games in a browser is to get the player right into the game, and not add additional hurdles.

- After the fullscreen request, browsers either show an additional passive message (mostly fine, but why all the hassle then, because this message can easily be missed by the user), or much much worse, show another message box which must be okay-ed by the user (yet another required user interaction). And the UX also seems to change all the time.

- And the absolutely worst offender: browsers hijack the Escape key to leave fullscreen mode, but since ancient times (at least since Doom?) the sacred Escape key is used to open the ingame menu.

- The whole asynchronous nature of the fullscreen API, but the above issues are more critical.

The pointerlock API has even worse issues, depending on browser. For instance I have demos where pointerlock should be activated when the mouse is pressed, and when the mouse is released, return to normal pointer mode (for instance because I want to manipulate an UI). This one for instance:

http://floooh.github.io/oryol-samples/asmjs/MeshViewer.html

Chrome is doing the right thing, it is showing a little popup, and remembers to not show it again on the same page until the page is refreshed.

FF and Safari now also just show a passive popup (which is a big step forward from FF's previous UI where a button had to be pressed before the pointerlock would active. BUT the popup shows *every single time*. On Safari the whole page is shifted down for the popup :/

When fullscreen mode and pointerlock mode is combined, for some reason the message popup never disappears on Chrome...

Etc etc etc... it doesn't even make much sense to write tickets, because the behaviour of the user-feedback still keeps changing all the time.

I'm doing the only sane thing now and try to avoid the 'real' fullscreen mode, and instead simply use 'soft fullscreen' where the canvas is stretched over the available window client area (doesn't fix the pointerlock UX problems though).

Cheers :)

-Floh.

[Jukka Jylänki]

Thanks for the details, I understand the issue now better.

There exists a draft for https://w3c.github.io/keyboard-lock/ to allow
getting the Esc key back to the application. I don't know what the
reception of that was/will be, but at least the existence of that spec
acknowledges that it has been considered a UX problem to not be able
to take control of certain keys.

> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-disc...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Flix]

Thanks for your answers. I think they're good enough for me.

I mainly asked about "real" fullscreen mode, because in the default emscripten shell there's already a "Fullscreen" button, and I wanted to make it work with a real fullscreen desktop resolution (if possible).

But now I think I'll leave everything as it is... it was not a priority for me.

Good to know that's not as easy as it seems in any case.