12 ms·
> This is about being able to play web videos without causing you to lose CPU performance and battery life. This has not really been supported on Linux or X11
by pdkl95 7y ago
> This is about being able to play web videos without causing you to lose CPU performance and battery life. This has not really been supported on Linux or X11
This is simply not true. I've regularly used hardware accelerated video on linux+X11 for over a decade. There are multiple ways for video playback to be accelerated, including hardware-specific video acceleration libraries like VDPAU and VAAPI, and hardware-agnostic acceleration using OpenGL (GLX). All of these options accelerate generic video playback steps like colorspace conversion, scaling. Most of these methods also provide direct hardware decoding of specific video codecs (h.264, mpeg1/2, vc1, wmv3).
Also, just like Wayland, hardware accelerated compositing (2D, not 3D!) of windows has been possible with X11 for more than a decade. Even my ancient window manager (Enlightenment DR16!) can manage X11's compositing.
Wayland was never required for any of these features.
- DCKing 7y agoDid you notice I said "web videos"? I'm talking about web browsers. I'm aware that mpv and vlc and others can use video acceleration okay, but they don't have complicated browser UI problems to solve.
- pdkl95 7y agoYes, I did notice that. There is nothing preventing a web browser from using the same methods and libraries. > they don't have complicated browser UI problems While not as complex, they do have a UI that overlays the video. However, the complexity of the UI doesn't affect video acceleration. Using libvdpau as an example, the X11 client provides[1] a separate child window[2]: >> VDPAU expects to own the entire drawable [...] it is recommended that applications create a dedicated window for the presentation queue target, as a child (grand-child, ...) of their top-level application window. The video playback happens in its own sandbox. Other non-video part of the UI should use their own child windows, isolated and independent of the video playback. The UI's child windows can be as complex as necessary, including overlaying the video[1]: >> Applications may also create child-windows of the presentation queue target, which will cover any presented video in the normal fashion. VDPAU implementations will not manipulate such child windows in any fashion. The child windows can even be alpha blended[3] with the video or other UI layers. Reading back video data (to implement features like CanvasRenderingContext2D.getImageData()) is easy: read the video window like you would read any X11 Drawable. What, exactly, was the "complicated UI problem" that supposedly wasn't possible to implement in X11? [1] https://vdpau.pages.freedesktop.org/libvdpau/group__api__winsys__x11.html#gabe3e13d71ee6bddfeb7363864ad383a3 https://vdpau.pages.freedesktop.org/libvdpau/group__api__win... [2] "window" is used in the X sense: a drawing context on an X server: https://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html#Overview_of_the_X_Window_System https://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/l... [3] X Render Extensison, section 8 https://www.x.org/releases/current/doc/renderproto/renderproto.txt https://www.x.org/releases/current/doc/renderproto/renderpro...
- DCKing 7y agoIf it is all so straightforward, what is your explanation for no web browser on Linux officially support video acceleration? Not Firefox, not Chrome, not Gnome Web, not Falkon, nothing. Despite video players just doing it. Just possibly, could it mean that it's actually not that straightforward in a browser? By the way, if you would read the actual base of the story here, you would know why it took Firefox's Wayland refactoring to actually pull this off [1]. [1]: https://mastransky.wordpress.com/2020/03/03/webgl-and-fgx-acceleration-on-wayland/ https://mastransky.wordpress.com/2020/03/03/webgl-and-fgx-ac...