Adding standalone Emscripten example.

[nicolasnoble]

Alternative version of #2492, as a fully standalone piece of code.

Currently available online at http://static.grumpycoder.net/pixel/example_emscripten.html

[ocornut]

Thank you Nicolas! This has been very welcome :)
This has been merged with small tweaks and fixes (see c1848b1).

[floooh]

Hmm... interesting. The sample (in the link above, but also when I compile on my own) "Oh Snaps" immediately for me when running in Chrome 73 on Windows 7 (Mac works fine).

This looks like a Chrome bug to me, I'll mention this on the emscripten discussion group, I know that the Chrome WASM guys are lurking there.

[nicolasnoble]

I can also try to ping some of these folks directly.

[ocornut]

FYI here's the version I compiled now (it's using WebGL 1.0 whereas Nicolas's PR was original WebGL 2.0):

http://www.dearimgui.org/webdemo/master/example_emscripten.html
http://www.dearimgui.org/webdemo/docking/example_emscripten.html

[floooh]

Looks good, in my release builds I also omit the "-s ASSERTIONS=1", I think this just adds additional checks into the generated code for debugging (C asserts are a separate thing).

But I'll also sift through my own build settings and see if there's anything else we could do...

I'm a bit confused by the size though... my own Dear ImGui sample's WASM blob is 644 KByte uncompressed and 234 KBytes compressed. I can't imagine that SDL2 adds so much overhead.

The SDL2 demo is 1.8 MB uncompressed... and you webserver doesn't seem to compress WASM files, but that's a different topic. Github pages serve wasm files as compressed, which reduces the download size by about 2.5 times.

[nicolasnoble]

My initial pass was mainly very paranoid in scope, enabling all possible warnings and safeguards. I'm certain we can reduce this drastically.

[floooh]

I tinkered around with more compile options and didn't achieve much (the Javascript part can be reduced quite a bit with enabling closure, but in the overall picture this isn't much).

I'm currently suspecting the SDL2 implementation. I'll do some more tinkering tomorrow or so :)

Btw, on Omar's request I have added a PR which replaces the shell-html with a version that stretches the WebGL canvas over the whole client area (a link to the sample is in the PR description), no code changes where necessary, the demo already tracks the current canvas size via SGL_GetWindowSize() and forwards this to ImGui. Here's the PR:

#2498

[floooh]

Btw, I did some more testing about the Aw Snap problem in Chrome on Windows. It depends on the optimization level, -Os and -O1 works, -O2 and -O3 doesn't (this is only in Chrome on Windows, Chrome on Mac/Linux and Firefox on Windows is fine).

I wrote a post on the emscripten group:

https://groups.google.com/forum/#!topic/emscripten-discuss/kuo92xLpP1Q

I haven't written a Chrome ticket yet. I'll probably write an experimental imgui_impl_emscripten.cpp which would replace the SDL GL context/window/event code with "emscripten-native" functions, to see how much this would reduce the code size, and whether this makes the crash go away (this would mean the problem is somewhere in the SDL2 code).

[floooh]

Here's an experimental / hacky "imgui_impl_emscripten.cpp" as a potential replacement of SDL2 in the emscripten sample:

https://github.com/floooh/imgui/blob/sdl-emsc/examples/imgui_impl_emscripten.cpp

...and the sample modified for this:

https://github.com/floooh/imgui/blob/sdl-emsc/examples/example_emscripten/main.cpp

...and the live demo:

http://floooh.github.io/oryol-sticky-tests/emsc-imgui-nosdl/example_emscripten.html

The size is reduced nearly by 2/3, from 1.8 MB (compressed: 808 KB), down to 687 KB (compressed: 330 KBytes). This is in the same ballpark as my sokol_app.h / sokol_gfx.h Dear ImGui sample (640 KB uncompressed, 230 KB compressed, no idea why it compresses so much better though).

@ocornut, in case you want to merge this, I'd need to do some more cleanup and probably implement a few more features around input before I could provide a PR.

[ocornut]

Thank you @Flooh.
I feel mostly we would need to

• Add enough commentary to make it clear that the primary purpose of that code is to make smaller downloads and that the user can still use glfw/sdl
• Massage the glfw/sdl example to allow make it clearer how to use them..
• Tidy up the code (follow imgui standards etc.)

I think I should work on adding the ImGuiKey_ constants and transitioning everyone to using them.. The design choice I made to use native keys is kind of getting in the way of portability..

[floooh]

Ok I'll keep that in mind, it'll be at least until after the Easter weekend until I'll get around returning to this and open a PR, guess that's ok though :)

(I also accidently used the wrong brace-style)...

I think the key-input-array isn't such a bad idea... at least I don't have any trouble with it...

If I had a wish free I think I would like some sort of minimal debouncing for the mouse buttons. It's not a problem for actual hardware mouse buttons, but quite noticeable for touchpads and touch displays (basically avoid that a mouse-up deletes the mouse-down from the same frame).

[floooh]

PS: maybe it's better to add a second emscripten-sample "example_emscripten_mini.cpp" and keep the SDL2-emscripten-sample as it is? This way the tradeoff is clearer, use SDL2 for portability and familiarity, but bigger sample size, or the emscripten API for minimal size.

[nicolasnoble]

Probably, yes. The main point of my very initial PR (#2492) was to demonstrate how to do this with the smallest set of changes possible.

[ocornut]

I agree, that’s a good idea!

[ocornut]

FYI : I've pushed 96ab68e and ce6e6da making the SDL+GL and GLFW+GL examples also build and run with Emscripten, without the need for a dedicated Emscripten example.