On Mon, Mar 31, 2014 at 1:33 PM, Trevor Linton <[email protected]>wrote:
> 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. > Oh, heh. I didn't even see those buttons the first time. > 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. > XZ + base64 + gzip, while extremely circuitous and slow, would probably be smaller than gzip on its own. > > -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]>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. > -- Chad Austin Technical Director, IMVU http://engineering.imvu.com <http://www.imvu.com/members/Chad/> http://chadaustin.me -- 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.
