
Graphics Team ships WebRender MVP - jandem
https://mozillagfx.wordpress.com/2019/05/21/graphics-team-ships-webrender-mvp/
======
gregwtmtno
This is an amazing achievement for the WebRender team, but users should manage
their expectations with regard to performance improvements.

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.

------
sambe
Shipping for Linux is waaay down the list:

[https://github.com/orgs/FirefoxGraphics/projects/1](https://github.com/orgs/FirefoxGraphics/projects/1)

I assume due to driver issues?

~~~
maggit
As a desktop Linux user, I'd guess it's harder to make it work right (because
of, among other things, driver issues) and it affects a smaller portion of the
user base of Firefox. Oh well.

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.

~~~
yoasif_
> Unfortunately, it fails hard with Wayland, putting no pixels on the screen.
> (In my experience)

It works for me in nightly, at least. Have you tried there?

~~~
maggit
No, only tried on stable. Looking forward to testing 67 when I get the update.

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 :)

------
pier25
So Windows 10 + Nvidia GPU is only 4%? Huh. I would have thought this
demographic would be larger.

I guess most users are on laptops where integrated Intel GPUs are more common.

~~~
noir_lord
I'm sorta in that 4%, I have an RTX2080 I use for gaming on my home desktop
but I'm only in Win10 _for_ gaming.

Hopefully I'll be able to use the RTX with Firefox and Fedora down the line
though (stably).

------
k_bx
Tremendous effort on a very complicated piece of software. I wish Firefox
would also catch up on less complicated but needed so greatly features which
are present in other browsers, like filling out credit card info and
autocomplete=email input fields autocompletion.

~~~
sambe
It's being rolled out:

[https://wiki.mozilla.org/Firefox/Features/Form_Autofill#Chil...](https://wiki.mozilla.org/Firefox/Features/Form_Autofill#Child_Pages)

------
jerheinze
The article forgot to mention the important fact that it's written in Rust!

~~~
Cynddl
Naive question: why is it important, compared to the developed features and
new architecture?

~~~
pygy_

        <rust-evangelism-strike-force>
            FEARLESS CONCURRENCY
        </rust-evangelism-strike-force>
    

Rust makes it easier to write bug-free concurrent code. Webrender relies on
this and I'm not sure Mozilla could have pulled it out in C++ in the same time
frame, if at all.

~~~
BubRoss
I think that's pretty presumptuous. My experience is that rust's checking is
great, but much easier and safer concurrency can still be enabled by some work
with data structures and program architecture.

~~~
throwupaway123
IMozilla engineers have specifically said Stylo (Quantum Style whatever) would
be impossible in C++, because they actually tried it in C++. Presumably it'd
be the same with WebRender.

~~~
BubRoss
Impossible is a strong word. Architecture makes a very big difference. They
can claim it is impossible, but it really doesn't make sense. I'm surprised
anyone would just take their word for it.

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.

------
xvilka
Hopefully they will rewrite the rest of Firefox in Rust as soon as possible.

~~~
inDigiNeous
... That is an gargantuan task. According to
[https://www.openhub.net/p/firefox/analyses/latest/languages_...](https://www.openhub.net/p/firefox/analyses/latest/languages_summary)
they have over 5.5 million lines of code written in C++.

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.

~~~
SketchySeaBeast
I'm confused as to why someone would even want them to change the codebase -
is this just an example of the "newer is better" problem we have here in tech?
Is there something glaringly obvious about Rust that would make the effort
worthwhile?

~~~
gridlockd
Because within that codebase there's an untold number of exploitable memory
errors which put users at risk. Browsers have critical security issues all the
time.

~~~
SketchySeaBeast
So would Rust remove all the potential exploits?

~~~
viraptor
A few of them. It won't stop logic errors (although enums help here) but it
will prevent buffer overflows, use-after-free, some cases of type confusion,
uninitialised reads, and a few other problems.

------
ncmncm
Here's hoping it is easy to switch off. Firefox has become extremely crashy,
running under Qubes, where the GPU is forbidden, despite my turning off
attempts at shader use everywhere I can find. E.g., even turning off "smooth
scrolling" made a substantial difference. But it still crashes, even just
loading a DDG search results page.

Advice welcome. (No, abandoning Qubes is not an option.)

~~~
yoasif_
Mozregression -
[https://mozilla.github.io/mozregression/](https://mozilla.github.io/mozregression/)
should help you figure out where it broke. You can open a bug with the commit
you found as "regressed by" \-
[https://wiki.mozilla.org/BMO/UserGuide/BugFields#regressed_b...](https://wiki.mozilla.org/BMO/UserGuide/BugFields#regressed_by)
to help developers track down how what they need to change to resolve the
issue.

