Graphics Team ships WebRender MVP(mozillagfx.wordpress.com) |
Graphics Team ships WebRender MVP(mozillagfx.wordpress.com) |
The reality is that Firefox's current rendering engine is highly tuned, and switching to a new engine without major performance regressions is impressive. Keep in mind, there may be performance improvements coming down the line.
https://github.com/orgs/FirefoxGraphics/projects/1
I assume due to driver issues?
Fortunately it's easy to opt in to, and in my experience works well on an oldish Intel chip.
Unfortunately, it fails hard with Wayland, putting no pixels on the screen. (In my experience) But I'm using it happily through XWayland.
It works for me in nightly, at least. Have you tried there?
I guess most users are on laptops where integrated Intel GPUs are more common.
Hopefully I'll be able to use the RTX with Firefox and Fedora down the line though (stably).
https://wiki.mozilla.org/Firefox/Features/Form_Autofill#Chil...
<rust-evangelism-strike-force>
FEARLESS CONCURRENCY
</rust-evangelism-strike-force>
That is an insane amount of code that would need to be rewritten, rechecked, retested and so on. Not going to happen anytime soon, if ever.
Advice welcome. (No, abandoning Qubes is not an option.)
I should clarify that I am talking about the situation when running Firefox with GDK_BACKEND=wayland.
UPDATE: Ooh! Firefox 67 in my package manager! I am happy to report that I am now able to use Firefox with WebRender on Wayland directly. One glitch so far: It leaves a one-pixel row transparent at the bottom of the screen. Weird :)
Trying to use raw threads and ad-hoc futures is going to be difficult, but fundamentally concurrency is about separating data by dependencies.
Dependency graphs that pass data around combined with lock free data structures can be used to isolate parts of the program so that dealing with concurrency is one generic part of the program.
(More on why I switched. I like to tweak things, and had gotten used to about 8 or so about:config customizations and a handful of Firefox extensions. The infection added tons of phoney about:config customizations, and it would have been tedious to identify which customizations were mine and which were the infection's. IIRC, if I had had a backup of my customizations unmixed with phoney customizations, I wouldn't have switched. I.e., basically I switched to avoid my having to learn how to back up my about:config settings and my choice of extensions. I recall spending some time with a search engine unsuccessfully trying to learn.)
TL;DR: Rust's concurrency guarantees made parallelizing CSS layout feasible. They tried it in C++ twice, and failed.
One of the early justifications for pursing Rust at all was security; an internal survey of security issues was done, and over half of them were memory-safety related. At the same time, browsers need speed. Traditionally, you get either speed or memory safety in a language; Rust gives you both.
However due to the other requirements (like performance) and its adoption at Mozilla, Rust is a real contender.
So is Python, JavaScript, Java, OCaml, Haskell...
A more distinguishing feature of Rust is not only that it is memory safe but also that it doesn’t have a GC.
In any case the presence of a single unsafe block can make the program no longer memory safe. Of course, if used appropriately, it vastly reduces the audit surface compared to something like C++.
This is a dealbreaker in a lot of contexts where garbage collection pauses would be unacceptable.