I'm using Firefox for pretty much everything including Google apps, but the one thing I do wish Firefox had is support for casting via Chromecast. In my experience, Chromecast support has been sorta spotty even on Chromium-based browsers like Vivaldi or Brave, forcing me to keep Chrome proper installed on my PC for when I want to cast a YouTube video onto a bigger screen. Is this bit of functionality too proprietary or entrenched enough that it cannot be ported to any non-Chromium browser?
The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
211–220 of 281 posts
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#212Earlier quoted context omitted.
There's already a JIT for JS coded in Rust: https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new... The overall goal is to have Firefox recoded in Rust, why would a JavaScript interpreter be left out? https://wiki.mozilla.org/Oxidation That's the whole point of Oxidation.
Of course they can do it. I just dont think is a clever move for them to do it. Firefox is having a hard time to compete with Chrome, and they took too long pursuing other goals, and just remembering one key feature they took a lot of time to implement, was making Firefox a the multi-process browser as Chrome. I mean, you would be ditching all this effort, rewriting it in Rust, spending key resources only to have som…
The only thing that will save Mozilla is Google coming under legal scrutiny for their privacy abuses or monopoly power.
Otherwise Mozilla lives because Google allows it and they allow it because it's mostly irrelevant and it's making itself even more irrelevant through stupidity like the MrRobot mini-scandal.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#213I'm using Firefox for pretty much everything including Google apps, but the one thing I do wish Firefox had is support for casting via Chromecast. In my experience, Chromecast support has been sorta spotty even on Chromium-based browsers like Vivaldi or Brave, forcing me to keep Chrome proper installed on my PC for when I want to cast a YouTube video onto a bigger screen. Is this bit of functionality too proprietary…
You can use VLC to Chromecast, it is a little bit fiddly but it works most of the time.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#214Earlier quoted context omitted.
Neither Firefox nor Chrome under Linux are capable of using GPU for video decoding. Only some distribution-specific Chromium builds do.
I seem to remember that some GPU acceleration under Linux was disabled voluntarily, on both Firefox and Chrome, because they actually ran much slower than CPU, probably due to bad drivers.
That’s certain GPU acceleration of rendering - specifically for Firefox I think compositing is disabled by default. It’s not the same as GPU accelerated video decoding which isn’t implemented in either browser, except via a set of patches for Chromium.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#215I wouldn't be surprised if improvements in Javascript execution will make webassembly obsolete. It already has a slim advantage of being 2x faster. And Javascript has so many advantages in terms of handling. No compilation step needed at all. And since it has modules widely supported now, it is a joy to code in native Javascript without any libraries like React&Co. Just look at how beautifully you can dynamically loa…
You are possibly right, but it would be sad if we our choices for writing programs with a UI are: write in javascript or compile to javascript. There are many languages out there, webASM would allow them to work without the massive pain of cross-compilation. I guess I am just an idealist screaming about how packet switched networks are unreliable and we should all use circuit switched networks.
The use case for wasm is basically doing cpu/memory intencive work in a worker process. In order to use wasm for UI you need lots of glue and ducttape, and the end result will be something using 2d canvas.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#216Earlier quoted context omitted.
Neither Firefox nor Chrome under Linux are capable of using GPU for video decoding. Only some distribution-specific Chromium builds do.
I seem to remember that some GPU acceleration under Linux was disabled voluntarily, on both Firefox and Chrome, because they actually ran much slower than CPU, probably due to bad drivers.
It is slower not due to drivers, but due to how the browsers[1] compose the final webpage. It does that using CPU, not GPU as on other operating systems, so hardware video decoding would involve moving the compressed video to GPU, waiting for it to decode, moving the decoded video back to RAM, do the composition, and then move the result back to GPU for display.
For hw decoding to have sense, GPU composition is needed. Hopefully webrender will bring that in for Linux too.
[1] Firefox actually, Chrome does use GPU composition. Chrome for ChromeOS even uses the same driver (libva+intel-vaapi-driver) as desktop linux for video decoding, Google just is not willing to support it on desktop. That's what some distributions enable in their Chromium builds.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#217Earlier quoted context omitted.
You are possibly right, but it would be sad if we our choices for writing programs with a UI are: write in javascript or compile to javascript. There are many languages out there, webASM would allow them to work without the massive pain of cross-compilation. I guess I am just an idealist screaming about how packet switched networks are unreliable and we should all use circuit switched networks.
If you want to use a different language, why would you care about the compile target? Compiling is done by the compiler. So to the developer it is the same. No matter if it comiles to Javascript or Webassembly. In the end, I don't think writing code for the web in languages other then Javascript will take off. Simply because Javascript will always evolve to fit this specific environment. And therefore will always be…
Cross compilation always comes at a performance cost. Moreover, it is another compilation target your compiler needs to support. When that compilation target is a high-level language, supporting it is harder. This means java-script as a compilation target is less likely to be added.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#218Earlier quoted context omitted.
It's not that they have huge userbase lately, so they could afford to lose it any further.
What would you consider a huge userbase? Firefox has 230 million monthly users, using FF for an average of over 5 hours per day. https://data.firefox.com/dashboard/user-activity
Given that Linux has 2% desktop market share (let's be generous) and Firefox has 10% (let's be generous the same way), that would mean that Linux has potential to be 20% of Firefox users. Is that something you are going to ignore?
Many executives would sell their families for less opportunity.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#219Earlier quoted context omitted.
JS tried to add (optional) type hints in the ES4 standard that was never adopted (outside of tangential things like ActionScript 3). It would be great if Typescript hints could pass right along to the JITs as useful optimization factors, but it currently sounds like TC39 would prefer not to recreate the disasters of ES4 and are staying out of type hints for the forseeable future. (Well-typed code should prevent most…
Yeah it's probably not worth it to add types to JS the language, but what if you could ship standard metadata files similar to source-maps that only included type information, which browsers could leverage to speed up compilation?
Adding types would probably slow down the code as some optimizations done by the engine wouldnt be allowed. Kinda like when you use bitwise operations for optimization only to find out they actually slow down the code.
We could hower add Interface and optional types as syntax sugar for runtime checks.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#220Earlier quoted context omitted.
Are there any solid benchmarck comparing JSC vs v8?
JSC has had a set of large metabenchmarks like JetStream2 for a while. We have been the fastest for a while but V8 is gaining, so the current advantage is significant but not earth shattering. The last time V8 had their own benchmark, they retired it right after we beat them on it and made a post saying that benchmarks are bad because people cheat on them. Around that time I stopped seeing google.com claim that I sho…
JSC is barely ever mentioned in the v8 team. They gave up wanting to be benchmark kings in the interest of having decent performance in Android markets (low-end and high).
Comments around cheating are likely aimed at OEMS who ship Chrome derived browsers and spin up the clock frequency when they detect certain benchmarks are running. These look great in online reviews.