Hi Chad, Did you click the "render" button at the top right? It just initializes (and doesn't attempt to render anything) on the first go. I'll re-add the closure compiler flag and submit a bug on it. As for the XZ stuff i'd love to see it implemented in server technologies, I've been trying to think of a way outside of base64 encoding (and including a 50KB deflater) that might keep the size down, however at that point i'm just trading download time for decompression in javascript time and doesn't really seem to be worth it, especially since base64 encoding the XZ compression would really kill the compression ratio.
-t On Monday, March 31, 2014 12:02:55 PM UTC-6, Chad Austin wrote: > > On Mon, Mar 31, 2014 at 9:08 AM, Trevor Linton > <[email protected]<javascript:> > > wrote: > >> Hi All, >> >> For the past few months i've been porting webkit to JavaScript using >> emscripten. >> > > Very cool! > > >> You can find a working demo (Firefox only) here: >> http://trevorlinton.github.io/webkit.js/demo.html >> > > It doesn't seem to render anything for me: Firefox 27.0.1 > > >> 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. 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!!! >> >> We would appreciate that too. :) Alas, we can't use the external memory > map file, and the array of 8-bit numbers static data is pretty wasteful. > >> >> 1. Closure compilers ran on it actually produce INVALID javascript, I >> get a syntax error of '--/a' which is nonsensical and fairly surprising. >> >> Fascinating! I've heard rumors of such things happening but never seen > it in practice. Can you narrow it down? > >> >> 1. 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. >> >> There are some folks at Google that are starting to resurrect the > discussion around web compression technologies. It's 2014, why haven't we > moved beyond gzip, etc. etc. LZMA is a huge win for certain types of > content, but broken proxy servers that assume any Content-Encoding header > implies gzip either need to be worked around or fixed. > > -- 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.
