Google Trumpets The Success Of Their Chrome "RenderingNG" Performance Initiative

[AdrianBc]

While I prefer Firefox for daily use, is undeniable Chrome is a faster browser, even on old and weak hardware, were current Firefox now struggles. Heck, even their notorious memory consumption is not that different from FF anymore.

No wonder why lightweight distros are migrating Chromium.

Unfortunately, I still find from time to time sites or links that work correctly only on either Chromium or Firefox but not on both.

So I have to use both, regardless if I would prefer only one of them.

Both of them have some annoying bugs.

None of them is able to "Print" a web page in the same way that they render it normally, but both lose page content in almost all Web pages by overlapping incorrectly various elements when in "Print" mode. This is annoying, because "Saving" a page also no longer works correctly with most modern script-generated non-static Web pages.

Since about a half a year ago, Chromium has made some change that on Linux with NVIDIA drivers causes a blanking of all screens from the moment when a file download finishes until the mouse is moved. All Chromium versions since then have the same behavior.

While downloading with Firefox does not interfere with the GPU drivers, since some time ago there was a change that introduced a bug where for certain file extensions I am not able to choose whether they must always be saved and not opened (i.e. if I choose, the choice is forgotten until next time), so I have to reply to the prompt that I want to save them at every download, which is annoying.

I wonder if such browser bugs appear only in certain specific user configurations or they are more widespread, e.g. if the recent Chromium blanking bug is strictly connected with the NVIDIA Linux drivers or it also appears with other GPUs or drivers.

As I use Chromium built from source, I wonder if the same blanking bug is present in the binary-distributed Chrome browser.

[M@GOid]

Unfortunately, I still find from time to time sites or links that work correctly only on either Chromium or Firefox but not on both.

So I have to use both, regardless if I would prefer only one of them.

Both of them have some annoying bugs.

None of them is able to "Print" a web page in the same way that they render it normally, but both lose page content in almost all Web pages by overlapping incorrectly various elements when in "Print" mode. This is annoying, because "Saving" a page also no longer works correctly with most modern script-generated non-static Web pages.

Since about a half a year ago, Chromium has made some change that on Linux with NVIDIA drivers causes a blanking of all screens from the moment when a file download finishes until the mouse is moved. All Chromium versions since then have the same behavior.

While downloading with Firefox does not interfere with the GPU drivers, since some time ago there was a change that introduced a bug where for certain file extensions I am not able to choose whether they must always be saved and not opened (i.e. if I choose, the choice is forgotten until next time), so I have to reply to the prompt that I want to save them at every download, which is annoying.

I wonder if such browser bugs appear only in certain specific user configurations or they are more widespread, e.g. if the recent Chromium blanking bug is strictly connected with the NVIDIA Linux drivers or it also appears with other GPUs or drivers.

As I use Chromium built from source, I wonder if the same blanking bug is present in the binary-distributed Chrome browser.

That is some unfunny bug you got there. Have you tried jumping between Gnome, KDE, XFCE to see if it is one of them, or even another distro?

[AdrianBc]

That is some unfunny bug you got there. Have you tried jumping between Gnome, KDE, XFCE to see if it is one of them, or even another distro?

On all my computers I am using Gentoo with XFCE, but I doubt that the bug can be related to XFCE.

Because I build Chromium from source, it might be something related to whatever configuration options are used for the Chromium build so I think that I should get some Chrome browser binary from another Linux distribution and try it.

When the bug first appeared some months ago, at some Chromium 8x.something (now I am using 92.something), I have verified that downgrading Chromium to any previous version removed the bug and that replacing the NVIDIA driver with various other versions did not influence the bug.

Since then, there have been at least 6 or 7 new versions of Chromium, but all of them behave identically on my computers, all of which have NVIDIA GPUs, so I cannot check if with another GPU there is any difference.

The blanking behavior of the GPU is the same as when the GPU driver is resetting the GPU after detecting a change in the monitor configuration, e.g. after powering on or off one of the monitors, it appears to cut completely the video signal going to the monitors and it stays so until I move the mouse, which presumably triggers some redrawing command and then all the monitors become active again.

It is very weird. I have been using Linux on all my desktops and laptops for almost 20 years, but until these recent Chromium versions I have never encountered any program affecting the GPU driver in such a way.

[AdamOne]

You don't measure that, you can calculate/estimate it. You start from wattage increase of a CPU when under load, then assuming some "average" cpu wattage you made first step towards mAh savings...

makes total sense

[arQon]

So those two environment variables I enabled alongside the changes above (MOZ_X11_EGL=1 and MOZ_USE_XINPUT2=1) are trouble.
Heads up if you're on an RX480.

I see now why EGL is blacklisted by glxinfo on my system. Was causing my system to freeze randomly when I was in Firefox. Took me a sec to figure out what the cause was since I changed a bunch of crap but had a good idea.

Jep, similar for the one machine I have that tries to use EGL: FF randomly cripples the entire machine to the point that even just trying to open a file manager window on /home takes over a minute.

So there are two currently-irreconcilable problems in play:
1) FF video accel only works with EGL.
2) FF EGL handling is apparently so broken that it can take out the entire machine.

AFAICT, rather than either sort out their code or file bugs against Mesa etc, the FF developers have decided that unless you have exactly the same HW that they do the option is blacklisted by default, and if you force-enable it you not only have little chance of it actually working but are apparently looking at a high risk of bringing down the whole system.

Which sucks kinda hard, since for the first 5 minutes or so of testing it I managed to get 1080p h264 playing pretty nicely, with a decent amount of HW offload and less than a 1% dropped frame rate. (Still not actually viable on 90% of the YT channels I watch, since those have gone all-in on 60FPS placebo e-peen only for 720p and up, which the Intel joke IGP in that box can't cope with, but nice for the few channels that still offer 1080p30).

https://xkcd.com/619/ is now *12 years* old, and aside from s/Flash/HTML5 it's still as true as it was back then. Still, at least FF is sort-of trying, even if it keeps failing. That's more than Chrome is, so I guess that's something...?

[Sonadow]

Which sucks kinda hard, since for the first 5 minutes or so of testing it I managed to get 1080p h264 playing pretty nicely, with a decent amount of HW offload and less than a 1% dropped frame rate. (Still not actually viable on 90% of the YT channels I watch, since those have gone all-in on 60FPS placebo e-peen only for 720p and up, which the Intel joke IGP in that box can't cope with, but nice for the few channels that still offer 1080p30).

A Haswell IPG can easily handle 720p60 and 1080p60 with ample headroom to spare.

If yours can barely keep up then it's the hardware that is busted or more likely the Linux drivers are full of shit. Windows users have no performance problems.

[perpetually high]

Those on Firefox that see this: can you report back what you see in about:support for the following:

Audio Backend pulse-rust
Max Channels 2
Preferred Sample Rate 44100
Roundtrip latency (standard deviation) 223.55ms (39.97)

I refreshed three times, and got three different numbers

(219.48 + 225.36 + 223.55) / 3 = 222.80ms average rountrip latency. Was curious how it compares to others to see if there can be any improvement there. Cheers.

[fuzz]

Those on Firefox that see this: can you report back what you see in about:support for the following:

Audio Backend pulse-rust
Max Channels 2
Preferred Sample Rate 44100
Roundtrip latency (standard deviation) 223.55ms (39.97)

I refreshed three times, and got three different numbers

(219.48 + 225.36 + 223.55) / 3 = 222.80ms average rountrip latency. Was curious how it compares to others to see if there can be any improvement there. Cheers.

Audio Backend pulse-rust
Max Channels 2
Preferred Sample Rate 48000
Roundtrip latency (standard deviation) 103.89ms (10.24)

[perpetually high]

Audio Backend pulse-rust
Max Channels 2
Preferred Sample Rate 48000
Roundtrip latency (standard deviation) 103.89ms (10.24)

Wow, nice. Thanks for sharing.

[arQon]

Roundtrip latency (standard deviation) 223.55ms (39.97)

I refreshed three times, and got three different numbers

(219.48 + 225.36 + 223.55) / 3 = 222.80ms average rountrip latency. Was curious how it compares to others to see if there can be any improvement there. Cheers.

50, 49, 46 for me - and that's on an ancient POS Atom box. So I think there's probably something wrong with your setup, since it's hard to imagine you're running something weaker than that.
No idea what, but at a minimum if you haven't fixed the pulse defaults those numbers are likely to be brokenly-misleading just from having to power up the sound HW every time.