Wow, nice! :) Notes on the issues you mentioned:
1. Not sure I follow that, can you please file a bug with a small testcase? 2. Very odd about chrome being so slow here. Profiler shows "idle" so it might be parsing or something else that is not actually JS execution. It's a good idea to file a bug on v8 so they can take a look at it. 3. Are you using latest emscripten? If so can you send me the final bitcode file (--save-bc, or one of the EMCC_DEBUG output files) and command you use to build, and I'll debug that locally? 4. Those should be removed on latest incoming, do you still see them there? (which version of emscripten are you on? use emcc -v to verify setup is ok) 5. I think I saw an issue filed earlier on a similar thing, was that this? If not, please file one with a testcase. 6. There is https://github.com/kripken/emscripten/issues/2188 but the far more optimal solution is to use a binary init file, --memory-init-file 1 which will save a lot of space. 7. I've seen closure in the past have similar issues. Can file a bug if you want, they tend to fix stuff like that quickly. But, with 6 and 8, i don't think closure will be needed, i don't use it anymore. 8. Native browser gzip support should be good enough - how big is the file with a mem init file and after gzip? 9. Does outlining not affect code size at all? Perhaps it is not being activated for some reason - does it work on smaller testcases for you? How are you using it? It should not be needed though, if you build sources with -Oz. 10. Notes on build flags: --llvm-opts 3 should not make any difference if -O2 or -O3 is already set As mentioned above, I would add --memory-init-file 1 -s NO_EXIT_RUNTIME=1 can reduce code size. see settings.js for meaning --llvm-lto 1 is worth trying. It can be good or bad for code size --llvm-lto 1 -s INLINING_LIMIT=1 is LTO but without outlining, also worth trying - Alon On Mon, Mar 31, 2014 at 9:08 AM, Trevor Linton <[email protected]>wrote: > Hi All, > > For the past few months i've been porting webkit to JavaScript using > emscripten. > > You can find a working demo (Firefox only) here: > http://trevorlinton.github.io/webkit.js/demo.html > You can find the project sources (compile settings are in common.gypi) > here: http://github.com/trevorlinton/webkit.js > > I have a few issues with Emscripten I haven't been able to work around: > > 1. It seems SDL with cairo inverts the red and green channels, this > from what I can see in the library code doesn't correctly handle RGBA masks > passed in to SDL_CreateRGBSurface. > 2. Chrome/Safari freeze for 30-90 seconds to what I can only determine > is garbage collection. > 3. Firefox fails to validate the ASM, I assume this is due to a > globally initialized variable but can't seem to track down where.. > 4. Emscripten warns of undefined symbols to > 'emscripten_gl<legacyfunction>' even though no GL code exists.. > 5. Using SDL as a worker fails since it still tries to use a native > canvas object in a Worker, rather than proxying it up to the host page. I > had to create some very harsh shims to make this work. > 6. Is there anyway memory can be initialized with a Uint32 rather than > Uint8? I'm my tests this would cut down my code size of webkit.js from 19MB > to 15MB!!! > 7. Closure compilers ran on it actually produce INVALID javascript, I > get a syntax error of '--/a' which is nonsensical and fairly surprising. > 8. There's no seemingly easy way to compress/inflate/deflate code > using XZ, this would be hugely helpful as it cuts the JS code down to > 3.5MB! I realize this will happen on a server level but would be VERY > helpful. > 9. Outlining my code does absolutely nothing, no matter what value I > set in the compiler. Any ideas why this would be? > 10. If you review common.gypi on the project to see the debug/release > compiler settings is there anything I can do to increase the speed/code > size? > > For reference i'm using 1.13.0 on MacOSX. > > -- > 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.
