Looks like the new WebGL context setup functions are in incoming :) I have updated my weekend engine to use them and it seems to work nicely. Also shaved 12kByte (uncompressed) from the generated code size compared to the EGL version.
Here's the new setup code: https://github.com/floooh/oryol/blob/f80b0c4c45a45f6282e4aee1ecf58c34f66168ca/code/Modules/Render/emsc/emscDisplayMgr.cc#L34 Compared to the EGL and GLFW versions: https://github.com/floooh/oryol/blob/f80b0c4c45a45f6282e4aee1ecf58c34f66168ca/code/Modules/Render/egl/eglDisplayMgr.cc#L44 https://github.com/floooh/oryol/blob/f80b0c4c45a45f6282e4aee1ecf58c34f66168ca/code/Modules/Render/glfw/glfwDisplayMgr.cc#L40 Demos have been updated as well: http://floooh.github.io/oryol/ Cheers (and many thanks!), -Floh. Am Dienstag, 22. Juli 2014 17:24:35 UTC+2 schrieb Floh: > > Cool :) If/when you get around to implement something, I'm happy to help > with testing! > > -Floh > > Am Dienstag, 22. Juli 2014 16:19:02 UTC+2 schrieb jj: >> >> This has been discussed before in different scenarios. I am very much in >> favor, I'll see about adding that in html5.h when I have a moment. Marked >> down https://github.com/kripken/emscripten/issues/2559. >> >> >> 2014-07-22 16:35 GMT+03:00 Floh <[email protected]>: >> >>> Hi, >>> >>> this is not really a feature request, more a thought in progress. I >>> think the current way to initialize a WebGL context via glut, EGL or SDL is >>> the right way for most code bases since it allows easy porting of existing >>> code. BUT both glutCreateWindow and EGL do little more then calling >>> Browser.createContext (haven't looked at the SDL wrapper yet), but each >>> wrapper comes with overhead (for instance, EGL has code which emulates the >>> EGL setup calls, even though most of this stuff isn't even used/needed, and >>> GLUT also initializes input event listening code). >>> >>> I was wondering whether it would make sense to have a minimalistic C >>> interface to Browser.createContext which would only allow to configure the >>> webGLContextAttributes (maybe emscripten_canvas_create_context()?). >>> >>> Also, the html5.h functionality goes a little bit into that direction to >>> offer emscripten-specific functionality with as little overhead as possible. >>> >>> My "usage scenario" is this: I want to create an absolutely minimalistic >>> 3D engine which really tries reduce client size as much as possible, for >>> input handling I will use the new html5.h functions, but for display >>> setup/management I still need to use either glut or EGL, both solutions >>> have drawbacks (glut has its own input handling, EGL doesn't allow yet to >>> configure some WebGL context attributes, and has some JS size overhead for >>> EGL functionality that isn't really needed in a WebGL environment). >>> >>> So... thoughts? As I said, the current solutions work just fine, but >>> each has some drawbacks/overhead, and I always found the emscripten_xxx API >>> functions very enjoyable to work with. >>> >>> Cheers, >>> -Floh. >>> >>> -- >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
