1. I'll see if I can put together a straight forward test case. I believe
I might be able to patch this and see if I can submit a push.
2. I agree, i'm unsure what exactly is happened although I did notice from
a few tests a huge spike in the garbage collection time then back to idle.
It could also be how i'm using emscripten/main loop. This never happened
when i used the emscripten_set_main_loop and simply had emscripten fire up
main. The current implementation has no main loop and acts like a shared
library. One shot timers are used to keep animation/rendering going
(webkit's Timer class is just now a wrapper around (essentially)
setTimeout/setInterval..
3. Yes, 1.13.0, you can find the produced byte codes
here: http://www.trueinteractions.com/bundle.tar.gz (note these are all
pulled together for the final .js with a handle full of files)
4. I'm at the latest, here's what is produced with emsdk list after an
update:
The following individual tools exist:
clang-3.2-64bit INSTALLED
clang-3.3-64bit INSTALLED
* clang-e1.13.0-64bit INSTALLED
* node-0.10.18-64bit INSTALLED
emscripten-1.5.6
emscripten-1.7.1
emscripten-1.7.8
emscripten-1.8.2 INSTALLED
emscripten-1.9.5
emscripten-1.10.4
emscripten-1.12.0 INSTALLED
* emscripten-1.13.0 INSTALLED
emscripten-incoming
emscripten-master
The following Emscripten SDK versions are available:
sdk-incoming-64bit
sdk-master-64bit
sdk-1.5.6-64bit
sdk-1.7.1-64bit
sdk-1.7.8-64bit
sdk-1.8.2-64bit INSTALLED
sdk-1.9.5-64bit
sdk-1.10.4-64bit
sdk-1.12.0-64bit INSTALLED
* sdk-1.13.0-64bit INSTALLED
5. Essentially when you use --proxy-to-worker the canvas object that
SDL_UpperBlit needs isn't available and/or not being proxied from what I
could tell.
6. Yeah, i'm hesitant to use a memory initialized file since its tricky in
certain contexts to ensure the file is properly included (as most users are
completely unaware of the file type and may assume its a debug file),
second reason is i'm unwary how some servers may look at shipping the
binary file / how it may be loaded. I've had tricky problems getting
binary data out of XmlHttpRequest objects due to some less than stellar
CDN/http servers out there. But I agree, its a perfect option and works for
95% of my use cases.
7. It would be nice to not need the closure compiler; it does take about a
half an hour to finish on my machine :/
8. It's 4.1 MB gzipped, about 3.5 with xz. I do wish there were more
sophisticated transport/loading/memory allocation techniques in JavaScript
:/.
9. None, does the -Oz option effectively disable outlining? I suppose its
not a huge problem, I just assumed outlining had no dependency/disabling
options.
10. I'll look into these optimizations, thanks!
On Monday, March 31, 2014 11:48:00 AM UTC-6, Alon Zakai wrote:
> 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]<javascript:>
> > 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] <javascript:>.
>> 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.
