Chrome 85 Beta Brings WebHID API For Better Gamepad Support, AVIF Image Decode

[phoronix]

Phoronix: Chrome 85 Beta Brings WebHID API For Better Gamepad Support, AVIF Image Decode

Following the recent Chrome 84 stable release, Google has now promoted Chrome 85 to beta as their latest feature update to this cross-platform web browser...

http://www.phoronix.com/scan.php?page=news_item&px=Chrome-85-Beta

[tildearrow]

and auto-upgrading of images served over HTTP from HTTPS sites.

I'm curious... how would that work?

[Danny3]

Image decode is nice, but how is the situation with video decode ?
Can Chromium hardware accelerate video decoding like Firefox on X11 or Wayland ?

[Danny3]

I'm curious... how would that work?

Probably they will waste some time into trying to see if each image can be retrieved from the same URL but with HTTPS instead of HTTP.
I assume this is meant for external images, coming from another domain than the one you're visiting.
Hopefully they will not make anything mandatory and break stuff that is not on HTTPS.

[mos87]

drop the Web* madness - we already have a general-purpose OS with plenty of drivers and user-space stuff.

[Installer]

For anyone interested in what’s the big deal with AVIF: I did a file-size reduction comparison with AVIF vs WebP compared to a MozJPEG reference images only last week. All three formats were encoded to the same structural dissimilarity score (DSSIM; a metric used to compare lossy image encoders at a comparable visual loss of quality). AVIF’s median savings was 50 % off the JPEG and the 85th percentile was about 40 %. WebP’s median was 31,5 % (so even lower than AVIF’s 85th %ile) and the 85th percentile was 20 %. Zero AVIF images ended up larger than the JPEG but 2,7 % of the WebP images were larger than the JPEG. WebP’s savings are nice and all, but pales in comparison with AVIF.

[Grinch]

All three formats were encoded to the same structural dissimilarity score (DSSIM; a metric used to compare lossy image encoders at a comparable visual loss of quality)

Why would you do this test and not include Jpeg XL at this point ?

[Installer]

Why would you do this test and not include Jpeg XL at this point ?

Three reasons: 1) AVIF support in browsers is right around the corner, 2) JPEG-XL isn't finalized yet, 3) and there have been a bunch of JPEG standards over the years; yet adoption for anything but the main format is pretty much non-existent.

[cl333r]

drop the Web* madness - we already have a general-purpose OS with plenty of drivers and user-space stuff.

Your needs != Google

[FireBurn]

Image decode is nice, but how is the situation with video decode ?
Can Chromium hardware accelerate video decoding like Firefox on X11 or Wayland ?

Video acceleration works with an extra patch which a lot of distros include. Gentoo doesn't currently but I have an overlay with it included which tracks, stable, beta and dev branches

I'd recommend using the h264ify plugin on machines that can only play h264, for machines that can do vp8 & vp9 i'd still recommend installing it but editing the plugin so it blocks av1 videos which no one hardware accelerates at the moment

If you use clang & thin lto you'll need to patch libdav1d as it crashes due to stack misalignment (that's how I figured out youtube had started serving up av1 videos)

The vaapi patch only works with the X11 backend, not the new Ozone backend so doesn't include Wayland support yet.

If you're running Chromium 85 or newer you'll have to start with --use-gl=desktop otherwise it defaults to angle where vaapi also isn't supported yet

So lots of caveats, I've a feeling vaapi will be enabled out of the box when support is added to Ozone and it becomes the new default