Nice - glad to see it's working out great! There was a minor glitch that I forgot to bump the version number in the original pull request, but Alon has bumped the version now to 1.21.10, so if anyone gets an intermittent error with "cannot read property .alpha of undefined", just pulling to latest should remedy that.
Thinking about the code sizes, we really need to start working on infrastructure or supporting https://github.com/kripken/emscripten/issues/2527 at some point that can trace each byte/character of the outputted .js file back to their exact source (library_x.js, preamble.js, etc.), so that we can track these in detail. That'd give a very detailed info about where the costs are. 2014-07-29 23:36 GMT+03:00 Floh <[email protected]>: > 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. > -- 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.
