The State Of Various Firefox Features

[liam]

While that's what we want to happen, the current C++ codebase for Firefox and Chrome have had an enormous amount of work put into optimizations and efficiency. I would love to be wrong, but I find it hard to believe that even an extremely well-done clean sheet redesign will be able to improve on performance any significant amount.

The real benefits, from what I understand, to Servo are in security, stability, and maintainability. If Servo can maintain the Gecko speed and memory usage or improve on them slightly and provide all of the good features of Firefox with less than one third as much code, that's a win.

Performance is definitely part of servo, as well. They are right on the cutting edge of speculative construction/rendering of html. The goal is for performance to scale with core count. This makes lots of sense with the huge number of smart phones out there that have relatively poor ipc, but many cores they can bring to bare.

[liam]

The last 3 releases have steadily gotten less responsive and more resource intensive.

How did you measure these? Are you sure the problem isn't some extension?
I've really not noticed this.

[Ericg]

Update:

A Mozilla developer got in touch with Michael and I in regards to the video playback portion of this overview.

The MSE Portion incorrectly states that Webm is enabled. It is not. Not sure how mine got turned on but somehow it did. Webm is currently disabled across the board due to outstanding bugs, it can be enabled manually within about:config.

According to the developer, H.264 is enabled by default on Windows Vista and up, as well as on OS X. It can be enabled under Linux if ffmpeg is installed and the user sets
media.fragmented-mp4.ffmpeg.enabled = true. (Though mine still said it wasn't available via youtube. Investigating.) Webm is expected to be fixed up and enebled in a few versions but no exact time-table is known as of now.

[Ericg]

I tried skia and font rendering was MUCH WORSE. I had to revert back to cairo. I'm running the open source drivers for my Radeon 6870 (oibaf mesa from git).

Interesting, what distribution molecule? I'm running Fedora 21 with Intel, I've got a radeonSI system back at my apartment though.

[molecule-eye]

Interesting, what distribution molecule? I'm running Fedora 21 with Intel, I've got a radeonSI system back at my apartment though.

Kubuntu 14.10, KDE 4.14.2, Kernel 4.0.0. I should say that my default font is the sans serif "Ubuntu" (and serif is "Droid serif"), so that might make a difference. I forgot to check against other fonts, but of course I could if you wanted.

[Bucic]

Yea, nice article.
Unfortunately for me MSE enabled still freezes video playback. Oh well, hopefully it will get fixed in the next release or two.
Another thing that could be mentioned are improvements to Firefox Hello. Right now it only supports two-way chat, but conferencing is planned; I opened a bug to track the progress of that here: https://bugzilla.mozilla.org/show_bug.cgi?id=1165635

Same here!
I have followed arch linux wiki to the bit and the playback just crashes.
Here's my workaround

https://bbs.archlinux.org/viewtopic.php?pid=1529535#p1529535

On windows it all works fine. But who watches internet motion pictures on linux anyway...

[Gusar]

On windows it all works fine. But who watches internet motion pictures on linux anyway...

Well, two things here:

First, it seems gstreamer-vaapi is extremely buggy. I've seen tons of reports about issues when it's installed for months now. Especially when it concerns web browsers, but even with dedicated gstreamer-based media players, such as Totem. Also, you have a wrapper involved there, which only increases the bugginess of everything. Don't use wrappers, r600 (and radeonsi) has native VAAPI support now - which means, instead of installing libva-vdpau-driver and setting LIBVA_DRIVER_NAME=vdpau, you install libva-mesa-driver and set LIBVA_DRIVER_NAME=gallium

Second, maybe it's just me, but I have the feeling Mozilla doesn't care about gstreamer anymore and is transitioning towards using ffmpeg directly for h264/aac, and internal libraries (libvpx, libvorbis, libopus) for webm. Which I must admit I like better, I've always regarded gstreamer as overkill. The one thing I'd like though, is the ability to use system versions of libvpx/libvorbis/libopus instead of the Firefox internal versions. Or better yet, just use ffmpeg for everything, ffmpeg's vp8 and vp9 decoders are much faster than libvpx.

Considering these two points, your workaround to disable the use of gstreamer in Firefox would be the absolutely correct thing to do.

[Bucic]

Well, two things here:

First, it seems gstreamer-vaapi is extremely buggy. I've seen tons of reports about issues when it's installed for months now. Especially when it concerns web browsers, but even with dedicated gstreamer-based media players, such as Totem. Also, you have a wrapper involved there, which only increases the bugginess of everything. Don't use wrappers, r600 (and radeonsi) has native VAAPI support now - which means, instead of installing libva-vdpau-driver and setting LIBVA_DRIVER_NAME=vdpau, you install libva-mesa-driver and set LIBVA_DRIVER_NAME=gallium

Second, maybe it's just me, but I have the feeling Mozilla doesn't care about gstreamer anymore and is transitioning towards using ffmpeg directly for h264/aac, and internal libraries (libvpx, libvorbis, libopus) for webm. Which I must admit I like better, I've always regarded gstreamer as overkill. The one thing I'd like though, is the ability to use system versions of libvpx/libvorbis/libopus instead of the Firefox internal versions. Or better yet, just use ffmpeg for everything, ffmpeg's vp8 and vp9 decoders are much faster than libvpx.

Considering these two points, your workaround to disable the use of gstreamer in Firefox would be the absolutely correct thing to do.

Thank you for your response!

This means the Arch Wiki is simply wrong as it is now.
OK, first, let's forget about both

https://wiki.archlinux.org/index.php/VA-API

https://wiki.archlinux.org/index.php/VDPAU

For the troubleshooting purposes I've comented out both environmental variables:
# moj VDPAU i VA-API
#export LIBVA_DRIVER_NAME=vdpau
#export VDPAU_DRIVER=r600
I've left any package installed per recommendations of the two articles linked above. I hope it is not needed.

Ad second:
It's all nice but I'd need specific instructions or at least the required arch package names. I use Arch but I'm a semi-noob.
As you could see I haven't got any response in the archwiki forum topic I've linked earlier.

[Gusar]

I did provide the Arch package name: libva-mesa-driver

To get both VAAPI and VDPAU, you need two packages - libva-mesa-driver and mesa-vdpau. Then export LIBVA_DRIVER_NAME=gallium and VDPAU_DRIVER=r600. You can check if both work by running vainfo and vdpauinfo (you need to install the vpdauinfo package first).

Which one to use depends on the player:

• gstreamer has practically no VDPAU support and buggy VAAPI support, so I wouldn't use gstreamer-based players at all, and I would uninstall gstreamer-vaapi
• VLC has good VDPAU support and not very good VAAPI support (no zero-copy), so configure it to use VDPAU
• mplayer only has VDPAU, so use that
• mpv is good with both VDPAU and VAAPI, but the developers care more about VDPAU, so use that
• web browsers... Chromium uses ffmpeg already, so that's that. With Firefox, disable gstreamer and activate ffmpeg. <- Note, this will actually be software decoding. Firefox doesn't provide hardware decoding in Linux, for Chromium I'm just now compiling it with a patch to enable VAAPI, we'll see how that goes in about an hour (Chromium takes a loooooooong time to compile).

[Azrael5]

firefox has to become more simple in enabling disalbing features as chrome is, and it must become also flexible depending on operating system matching proper hardware acceleration: example XP adopt dx9 and d3d sound while since vista dx11 has replaced dx9 and d3d sound was abandoned... developers have to use their brain.