I'm checking into it, there is something strange, Chrome's V8 ends up converging around 0.17 seconds after 12/15 iterations, 0.085 native (exact same code compiled into C++ with a opengl shim) is not shabby at all. But i'm still flabbergasted as to why Firefox hits down into the 0.09 area, i'm probably going to have to chalk this up to some sort of latency in implementations as the difference in time is getting a bit too low to accurately compare apples-to-apples between implementations (even if one callback had a 0.05 latency that could be huge in the timing.
At any rate, if you find any other ways to make it faster (or smaller) please let me know! With that optimization jump its now pretty damn on-par with current-gen renderers performance for 99% of most users use cases. On Monday, June 23, 2014 8:12:38 PM UTC-6, Alon Zakai wrote: > > Heh, I'd expect it to be competitive with native, not better ;) My guess > is a measurement artifact, like something in the browser is async and > returns immediately, and is executed later after the benchmark already > reports the result. Or, perhaps hardware accelerated rendering is not used > in the native build for some reason, or something like that? > > - Alon > > > > On Mon, Jun 23, 2014 at 5:39 PM, Trevor Linton <[email protected] > <javascript:>> wrote: > >> *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] <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.
