-
Notifications
You must be signed in to change notification settings - Fork 440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emscripten application #300
Conversation
4b89b04
to
a976270
Compare
55dfa4f
to
2d9d36d
Compare
edafc8d
to
5d91571
Compare
@mosra Is it sensible to really port all of the examples? Should I keep a macro platform switch to demonstrate that Sdl2Application is compatibly replaceable with EmscriptenApplication? |
The EmscriptenApplication should be the sensible default for Emscripten, but Sdl2Application is still the sensible default basically everywhere else. So, yes there should be a platform switch between EmscriptenApplication, Sdl2Application (and AndroidApplication) because the ports branch still needs to compile on all platforms, but there's no need for having an option to use SDL2 on Emscripten. |
cb6eb58
to
f815ba5
Compare
@mosra This is ready for review! If there is any bigger tasks I completely overlooked, send those over first so I can work on them in parallel to the rest of the review 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally got to review this, sorry about the delay. Should be mostly minor things, no drastic design-changing requests from me ;) Also I think it isn't missing any large thing, apart from the touch events which I have to do for all the apps anyway.
Thank you!
586d281
to
7014d16
Compare
@mosra This is also ready for the next review pass, then I'll squash the remaining commits down into one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was about to merge, but the EM_JS
thing scared me off -- and you can save one include in the header :)
CMakeLists.txt
Outdated
@@ -103,7 +103,7 @@ option(WITH_SHADERS "Build Shaders library" ON) | |||
cmake_dependent_option(WITH_TEXT "Build Text library" ON "NOT WITH_FONTCONVERTER;NOT WITH_MAGNUMFONT;NOT WITH_MAGNUMFONTCONVERTER" ON) | |||
cmake_dependent_option(WITH_TEXTURETOOLS "Build TextureTools library" ON "NOT WITH_TEXT;NOT WITH_DISTANCEFIELDCONVERTER" ON) | |||
cmake_dependent_option(WITH_TRADE "Build Trade library" ON "NOT WITH_MESHTOOLS;NOT WITH_PRIMITIVES;NOT WITH_IMAGECONVERTER;NOT WITH_ANYIMAGEIMPORTER;NOT WITH_ANYIMAGECONVERTER;NOT WITH_ANYSCENEIMPORTER;NOT WITH_OBJIMPORTER;NOT WITH_TGAIMAGECONVERTER;NOT WITH_TGAIMPORTER" ON) | |||
cmake_dependent_option(WITH_GL "Build GL library" ON "NOT WITH_SHADERS;NOT WITH_GL_INFO;NOT WITH_ANDROIDAPPLICATION;NOT WITH_WINDOWLESSIOSAPPLICATION;NOT WITH_CGLCONTEXT;NOT WITH_GLXAPPLICATION;NOT WITH_GLXCONTEXT;NOT WITH_XEGLAPPLICATION;NOT WITH_WINDOWLESSWGLAPPLICATION;NOT WITH_WGLCONTEXT;NOT WITH_WINDOWLESSWINDOWSEGLAPPLICATION;NOT WITH_DISTANCEFIELDCONVERTER" ON) | |||
cmake_dependent_option(WITH_GL "Build GL library" ON "NOT WITH_SHADERS;NOT WITH_GL_INFO;NOT WITH_ANDROIDAPPLICATION;NOT WITH_WINDOWLESSIOSAPPLICATION;NOT WITH_CGLCONTEXT;NOT WITH_GLXAPPLICATION;NOT WITH_GLXCONTEXT;NOT WITH_XEGLAPPLICATION;NOT WITH_WINDOWLESSWGLAPPLICATION;NOT WITH_WGLCONTEXT;NOT WITH_WINDOWLESSWINDOWSEGLAPPLICATION;NOT WITH_EMSCRIPTENAPPLICATION;NOT WITH_DISTANCEFIELDCONVERTER" ON) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The app has #ifndef MAGNUM_TARGET_GL
and should thus theoretically work when WITH_GL is disabled, no? The SDL and GLFW apps are not here either.
To be extra sure, can you verify it builds when WITH_GL
is disabled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was a very good idea, found quite a couple of issues with the GL-less build.
I think the SDL has compile issues without GL, though 🤔 That appears to be the combination of emscripten and non-GL. That would not make sense for Sdl2Application to support, though, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
SDL should compile w/o GL mainly on desktop and mobile (Vulkan), I don't care much if it breaks on Emscripten tho, since it was superseded by your implementation now :) For EmscriptenApplication we should be able to turn off GL either for WebGPU or 3rd party renderers.
doc/platforms-html5.dox
Outdated
@@ -351,7 +351,7 @@ Module.doNotCaptureKeyboard = true; | |||
@endcode | |||
|
|||
The above is implicitly set for windowless apps, because these don't have any | |||
event loop. | |||
event loop, and is not supported by @ref Platform::EmscriptenApplication. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would instead mention that there's WindowlessEglApplication
that can be used, instead of saying this is not supported by EmscriptenApp.
/* The resize event is not fired on window resize, so poll for the canvas | ||
size here. But only if the window was requested to be resizable, to | ||
avoid resizing the canvas when the user doesn't want that. Related | ||
issue: https://github.com/kripken/emscripten/issues/1731 */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This AFAIK holds for emscripten_set_resize_callback()
as well, right? Maybe update the comment to make it clear it's not just a copypasted assumption from Sdl2App.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question, I think it may actually fire even.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it holds, see the note in the emscripten documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. That led me to think we could attach the callback to the window instead of this ugly polling. Will try this locally.
Codecov Report
@@ Coverage Diff @@
## master #300 +/- ##
=========================================
+ Coverage 71.39% 71.4% +0.01%
=========================================
Files 349 349
Lines 17598 17595 -3
=========================================
Hits 12564 12564
+ Misses 5034 5031 -3
Continue to review full report at Codecov.
|
By mistake I thought it's the same as in Emscripten's SDL, but there Emscripten does some emulation to ensure windowSize() == framebufferSize(). For the resize event it's possible to hook into the window resize callback instead of polling for the size every frame, That's much more efficient.
Also store them as references and not pointers.
The exec() should return int to be API-compatible with other implementations.
And expose it to the users.
Signed-off-by: Squareys <squareys@googlemail.com>
Signed-off-by: Squareys <squareys@googlemail.com> Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>
Signed-off-by: Squareys <squareys@googlemail.com>
c6f242e
to
733d417
Compare
🎉 |
@mosra Thanks for merging! And especially thanks for all the great cleanup work! 🎉 |
Hi @mosra !
This is the pullrequest for the light-weight emscripten HTML5 API based application hackathon project.
Cheers, Jonathan
TODO
[ ] fullscreen handling=>emscripten_(request|exit)_fullscreen()
on user gestures as Application does not usually handle this.