We're currently rewriting most of the graphics rendering of Firefox (with what is called the WebRender project). This is the first time Linux users will have hardware accelerated rendering by default, and is a pre-requisite to take real advantage of hardware-accelerated video decoding. It's enabled on some configuration in Nightly builds [0], and it's being worked on actively. If you want to know more, the graphics teams has a blog where updates are periodically posted about what is happening, often with interesting insight about the innards of a web browser rendering stack [1].
Once rendering is hardware accelerated, it makes sense to look into hardware video decoding. Doing hardware video decoding without hardware rendering roughly means we need to read back from GPU memory into main memory, composite the image in software, and then upload back to the GPU to display, which is super super inefficient.
TLDR: if js gets direct control of GPU, it can read/modify present and past screens.
Maybe after Wayland implementations get good enough, distributions will make hw acceleration work securely with wayland compositors, probably years? Just guessing.
Playing video on youtube is easy, but performance sucks due to bloated youtube website. Performance of the same video URL in empty page with video player is much better, close to that in video player with CPU only.
If you need GPU acceleration, you can use something like youtube-dl or mpv to play videos on a URL in a video player.
I do wonder how much could be saved on energy bills for one of the most common uses of the net (watching videos), especially for folk in developing nations.
Oh dear. Video acceleration means GPU is doing what CPU would be else doing. Which means user threads get less indirect access to GPU. Which is a potential security risk, because GPUs and GL are designed to perform, not to secure data.
VA-API is not mentioned in the question at all. It is the most common api for video acceleration, but there are others - direct vdpau, or nvdec.
