Google Chrome 108 Released As Last Major Version For 2022

[phoronix]

Phoronix: Google Chrome 108 Released As Last Major Version For 2022

Google released Chrome 108 on Tuesday that is the last major feature update for 2022 with this cross-platform web browser...

https://www.phoronix.com/news/Chrome-108-Released

[aksdb]

Sadly one of the (or at least my?) main issues is still open (and probably will be a for a long while): working hardware video decoding. Currently the whole rendering stack is in the middle of rework and it is kind of a mess. Depending on the usage of Wayland, X11, Nvidia, AMD or Intel you need to enable or disable the new renderer, enable or disable Vulkan, enable or disable specific egl versions, and even then it might simply not work.

I am not criticizing their work ... reading the associated tickets the problem space is horribly complex and I really wouldn't want to be in their shoes. But as a user the current status quo still sucks.

(And before someone says "just use Firefox": neither GeForceNow nor XBox Game Streaming work with Firefox. And without hardware decoding, the visual artifacts are just aweful).

[torsionbar28]

My beef with Chrome, aside from the spyware aspect, is the rash of security flaws. It feels like once a month, for the past several months, a critical VPR is issued for Chrome, requiring my team to stop work and go patch all the workstations and servers. Why so many critical vulns in such a short amount of time??

[M@GOid]

My beef with Chrome, aside from the spyware aspect, is the rash of security flaws. It feels like once a month, for the past several months, a critical VPR is issued for Chrome, requiring my team to stop work and go patch all the workstations and servers. Why so many critical vulns in such a short amount of time??

I guess that is probably because they are in the sights of every single security researcher and scum cyber-criminals out there, just like IE was a decade ago. If Firefox had the same market share Chrome and its siblings have right now, they would had the same if not more security issues being put in the spotlight.

[M@GOid]

Sadly one of the (or at least my?) main issues is still open (and probably will be a for a long while): working hardware video decoding. Currently the whole rendering stack is in the middle of rework and it is kind of a mess. Depending on the usage of Wayland, X11, Nvidia, AMD or Intel you need to enable or disable the new renderer, enable or disable Vulkan, enable or disable specific egl versions, and even then it might simply not work.

I am not criticizing their work ... reading the associated tickets the problem space is horribly complex and I really wouldn't want to be in their shoes. But as a user the current status quo still sucks.

(And before someone says "just use Firefox": neither GeForceNow nor XBox Game Streaming work with Firefox. And without hardware decoding, the visual artifacts are just aweful).

They dug that grave didn't they? Video Acceleration could have been in their priority list, but some blessed soul thought it was better to keep the Linux peasant's complains under the rug and now, they had a heck of a hill over their heads.

[aksdb]

They dug that grave didn't they? Video Acceleration could have been in their priority list, but some blessed soul thought it was better to keep the Linux peasant's complains under the rug and now, they had a heck of a hill over their heads.

I think it's not that simple. From what I understand with my superficial knowledge, depending on the render path it's hard to get the hardware decoder to project the decoded video stream in the correct format. Might be it's a different color space and needs migration first, might be that it's simply not that easy to get the correct "plane" to render on in a way that the hardware decoder can work with.

[clapbr]

• [22626:22626:1201/172828.876406:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RG_88, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.895169:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RED_8, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.895343:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RG_88, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.897198:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RED_8, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.897376:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RG_88, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.899709:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RED_8, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.899888:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RG_88, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.902880:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RED_8, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.903143:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RG_88, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.905341:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RED_8, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172828.905465:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RG_88, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172829.037262:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RED_8, share_between_threads: 0, gmb_type: shared_memory
• [22626:22626:1201/172829.037399:ERROR:shared_image_factory.cc(575)] : Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: RG_88, share_between_threads: 0, gmb_type: shared_memory

Just the last breakage for me, of many.

[johnp]

I have been using Microsoft Edge (same source code with Google Chrome, different name) in Manjaro Linux, and it works fine for me.

I do not know if hardware acceleration is enabled in Microsoft Edge. What are the specific flags I should look at?

I have read in the past, Google provides Chrome with hardware acceleration in ChromeOS (their own Linux distribution), but have it disabled in other Linux distributions, probably because they consider the other Linux distributions as competition.

[SuitedUpDev]

They dug that grave didn't they? Video Acceleration could have been in their priority list, but some blessed soul thought it was better to keep the Linux peasant's complains under the rug and now, they had a heck of a hill over their heads.

It's simple as this. There are multiple rendering path's that can be taken for a wide variety hardware and software configurations.

Given the three big GPU vendors (Intel, NVIDIA and AMD) there are 1 or multiple renderings paths that can be taken.

- For Intel, it's pretty straight forward. They invented and opensourced their Video Acceleration API, also called VA-API.
- For NVIDIA hardware, there are different options. VDPAU (NVIDIA's answer to VA-API), NVENC / NVDECODE API's and VA-API. However, here are things are already getting messy.
VDPAU and NVENC / NVDECODE are only supports by their proprietary drivers.
So basically no VA-API, if you use NVIDIA's (proprietary) drivers*. If you use the nouveau driver (the open source NVIDIA driver), you have access to both VDPAU and VA-API support.
- AMD supports both VDPAU, VA-API and AMF (Advanced Media Framework, but we will ignore this one right now).

So VDPAU, VA-API and NVENC / NVDEC are the three available flavours. Most software primarly target supporting VA-API, since that covers the most hardware (Intel CPU's with iGPU and AMD GPU's). Chrome / Chromium supports VA-API, VLC supports VA-API and VDPAU, GStreamer supports VA-API and NVDECODE but not VDPAU.

Not to mention, that besides these 3 options there is also the "issue" of Xorg vs (X)Wayland. Those are alot of variables and renderings paths to take into consideration and alot of support you have to build in your browser.

It would be great if NVIDIA, just took their Linux support serious and added VA-API support in their drivers like the rest of the vendors. Instead of trying to push their own thing (VDPAU). That way we (Linux desktop users) we could seriously make Video Accelerated playback happen.

More information on what software supports which hardware video acceleration, I wanna redirect to you to Arch's Wiki Page on the subject. https://wiki.archlinux.org/title/Har...o_acceleration

* The asteriks being, that there are wrappers available that translate VA-API calls to NVDEC / NVENC (or CUDA) like: https://github.com/elFarto/nvidia-vaapi-driver. However those can be a bit buggy from time to time. Also NVIDIA's 'open-gpu-kernel-modules' driver, does not support VA-API.