*Alon --* Thanks so much for the hint! I totally blanked making sure the ASM_JS was set back to 1 from 0, this had a huge improvement in performance. Chrome's render speed dropped in half from 2.3 second for complex SVG/text/cairo/freeytpe tests with gradients to 1.1 seconds.
But Firefox, holy crap... it went from 2.6 seconds to 0.098 seconds... (no joke, i dumped all of my cache and restarted then changed the file name path because I thought it was a caching issue). I need to stop and put this in perspective... Exact same rendering test in native C++ code takes 0.83 seconds (100 run average)..... I'm a bit confused if there's still some sort of trickery going on as there's no way it could possibly be an order of magnitude faster... Here's the final link command: /Users/tlinton/Library/Emscripten/emscripten/1.16.0/emcc -s EXPORTED_FUNCTIONS="['_main','_scalefactor','_createWebKit','_setHtml','_setTransparent','_scrollBy','_resize']" --embed-files ../src/assets/fontconfig/fonts@/usr/share/fonts --embed-files ../src/assets/fontconfig/config/fonts.conf@/etc/fonts/fonts.conf --embed-files ../src/assets/fontconfig/cache@/usr/local/var/cache/fontconfig -s FULL_ES2=1 -o webkit.html -s ASM_JS=1 -s OUTLINING_LIMIT=100000 -s TOTAL_MEMORY=100663296 -O3 --llvm-opts 3 --llvm-lto 3 -g0 obj/src/webkit.WebView.o obj/src/webkit.Main.o libxml.bc libjpeg_turbo.bc libpng.bc libfreetype.bc libharfbuzz.bc libcairo.bc libzlib.bc libpixman.bc libfontconfig.bc libwebcore_xml.bc libwebcore_wtf.bc libwebcore_svg.bc libwebcore_loader.bc libwebcore_html.bc libwebcore_dom.bc libwebcore_css.bc libwebcore_rendering.bc libwebcore_page.bc libwebcore_style.bc libwebcore_derived.bc libwebcore_platform.bc libwebcore_history.bc libwebcore_editing.bc libwebcore_angle.bc libwebcore_support.bc You can find the source at http://trevorlinton.github.io/webkit.bin.js (and subsequently the demo at http://trevorlinton.github.io. *Sergey--* Certainly there's a few odds and ends that need to be corrected on Cairo, you can find the commits in the webkit.js folder, mostly around dealing with cairo's, uhm, "eager" use of casting function signatures. In addition XML parsing is fairly straight forward. In all honesty it would be interesting to see a C# runtime compiled down into a javascript asm.js loop. I'm unsure what additional efforts there would be beyond that but I know of quite a few projects that would benefit from it (including Microsoft's own). I wonder if like SVG, you could write its own layout document/style tree for XAML, then add in IDL bindings that instead of javascript could integrate more elegantly into a C# compiled down javascript reduction. I only say this as you'd save yourself some headaches implementing things such as resource fetching, compositing, hi-dpi support and all of the other anxilary pain in the butt features. You effectively could just fork webkit.js and start adding in a new style parsing tree similar to SVG then change the compiler to simply not include the HTML/CSS/SVG tree. Just a thought... - Trevor On Monday, June 23, 2014 12:06:45 PM UTC-6, Sergey Kurdakov wrote: > > Hi Trevor, > > this is really great example which might inspire for other similar > projects. > > One which immediately came to me is possibility to run silverlight in > browser without plugins. > > Moonlight code is very similar to your webkit port: it renderes xaml using > cairo for all text and graphics. And you managed to have this kind of > rendering to be hardware accelerated. Then it is trivial to submit a tree > of xaml/xml elements from parser to render and JSIL project will provide > compilation of C# to javascript - so, essentially it is possible to have a > solution which will allow > current silverlight projects to work without ms plugin. And due to > attempts of firefox team to get rid of silverlight plugin it is very > important for those who wrote a lot of code to have some even slow fallback > solution. > > quite possibly similar approach might contribute to development of more > robust javascript flash simulation in project Shumway > https://github.com/mozilla/shumway > > so, thanks for inspirational project. I hope it will lead in few years to > a situation where emscripten/javascript can replace all popular plugins > like flash and silverlight in browser, and will allow to retain on the web > all hard earned software even if initial vendor drops any support. > > Regards > Sergey > > -- 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.
