Firefox 78.0 Released - Also Serves As The Newest ESR Version

[bug77]

Overall a great browser.

Just too bad a few things are missing:

• Dialog element
• system-ui font-family
• Private class fields

Man, I really thought you'd stop whining after Firefox implemented date and time pickers. Joke's on me, I guess.

[johnp117]

caligula Native Wayland, VAAPI and dmabuf aren't enabled by default yet. Check this post on how to enable those manually (things may break).

[treba]

Not sure what I'm missing, but I tried watching a H264 1080p video via Youtube/FF78. Don't see much difference in CPU utilization when using Wayland or X11. The CPU use is rather high, up to 30%. My setup:
- kernel 5.7.6
- mesa 20.1.2
- gnome 3.36 (start in x11/wayland mode via gdm)
- skylake notebook igpu
- firefox 78

Yes, I forced webrender stuff on.

See https://mastransky.wordpress.com/202...pi-on-wayland/ - you need a bit more atm.

[caligula]

Not sure what I'm missing, but I tried watching a H264 1080p video via Youtube/FF78. Don't see much difference in CPU utilization when using Wayland or X11. The CPU use is rather high, up to 30%. My setup:
- kernel 5.7.6
- mesa 20.1.2
- gnome 3.36 (start in x11/wayland mode via gdm)
- skylake notebook igpu
- firefox 78

Yes, I forced webrender stuff on.

[treba]

You are in the wrong path. It can be done also for Xorg without any problems. They simply don't want! My question is: Why?

To reiterate: video in a browser engine is different from a simple player. You want to decode the video in a sandboxed process, isolated from the one doing the rendering. So you need a way to share memory on the GPU. That's what DMABUF is for. X11 pixmaps apparently can also be used - but that's apparently much more bug prone than EGL+DMABUF, which is how things on Wayland and modern X11 is done. That's you answer.

Edit: a good video player would do the same IMO. Videos are often from untrusted sources - decoding them without proper isolation, well, see https://www.vice.com/en_us/article/v...ster-hernandez

[uid313]

uid313 HTML5 Dialog just landed in Nightly.

I don't know about that. dom.dialog_element.enabled is still false on my system running nightly and is marked as default false.
So it seems it is still not supported. I don't know why it has taken them this so long, it seems like a good feature to have a semantic markup for dialogs, that would be good for like robots, search engines, accessibility, screen readers, etc.

Oh, it got reverted from nightly.

https://bugzilla.mozilla.org/show_bug.cgi?id=1645046

Hopefully it will be fixed soon and maybe pushed again tomorrow or very soon. I wish they had this feature a year ago.

[You-]

I think there should be a rule where you cannot complain about any OSS when using nVidia. it almost always invalidates anything that has been said.

[johnp117]

Guest
Just use the VAAPI-vdpau bridge (libva-vdpau-driver) if you must use VDPAU. You may need to disable the built-in ffmpeg (licensing reasons) via media.ffvpx.enabled:false in addition to that. Note that there's already the first crash reported in NVIDIAs vdpau_drv_video.so.

There is no will !

Yes, there's no person interested to invest copious amounts of time into NVIDIAs bs when VAAPI/dmabuf hasn't even been finished yet.


uid313 HTML5 Dialog just landed in Nightly.

[uid313]

Overall a great browser.

Just too bad a few things are missing:

• Dialog element
• system-ui font-family
• Private class fields

[treba]

Well, I've just made some tests. My ffmpeg is linked with libvdpau, but ffplay cannot use it (in fact, there is no video engine utilization). ffplay can use the decoder h264_cuvid (command line: ffplay -vcodec h264_cuvid FILE.mp4). The absurd thing is I can decode, using cuvid, also other vdpau unsupported video files via hardware. I always checked the Video Engine Utilization from Nvidia Settings.
So, there is no reasons not to implement hardware acceleration using the vdpau interface in Firefox, Chrome, Chormium(s) and whatever browsers will make tomorrow. There is no will !

The video engine utilization and the gpu and the cpu is not the same using vdpau or cuvid.

AFAIK the main problem is DMABUF. As long as the decoded video has to make a round-trip from vram to ram and back there's apparently hardly any benefit of doing hardware video decoding. The nvidia proprietary driver can't use dmabuf for license reasons and the kernel people don't seem to be willing to change that. So IIUC nvidia would need to have something similar in their kernel module or FF could use pixmaps somehow - something they tried but disabled as it was found to be bug prone on nvidia (1).

So well, the easiest would probably be if nvidia would simply allow their firmware to be shipped with free drivers - just as other good linux citizens do

1: https://searchfox.org/mozilla-centra...List.yaml#4179