5 ms·

Compiz/beryl exists since 2006 which is 14 years ago. And this was really impressive working software, not just a demo. So impressve in fact, that it made many

by sprash 7y ago

Compiz/beryl exists since 2006 which is 14 years ago. And this was really impressive working software, not just a demo. So impressve in fact, that it made many people switch to Linux. Windows Vista with a truly 3D accelerated desktop came after that. Also this "news" does not tell that Wayland is finally delivering. It tells us that the Wayland implementation of Firefox has reached feature party to X11 for very specific subsystems.

DCKing 7y ago
You're completely misunderstanding what this is about. Hardware video acceleration is not about rendering 3D graphics. 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, whereas it has been supported on Windows and Mac by almost all browsers for over a decade. The fact that this will be officially supported by a major browser vendor on Wayland first should tell you something.
- sprash 7y ago
  > Hardware video acceleration All video players on X11 have VDPAU support since ages. This is a Firefox specific problem which could be solved more easy on X11. > The fact that this will be officially supported by a major browser vendor on Wayland first should tell you something. It just tells me that Mozilla/Firefox really doesn't care about Linux because it took them 14 years since VDPAU works reliably on Linux to implement it.
  - DCKing 7y ago
    Gnome Web, Midori, Falkon and Konqueror are browsers that only run on the "free" desktop, and don't support VAAPI/VDPAU either. Google built an entire OS based on Gentoo, and the desktop Linux build of Chrome doesn't support video acceleration either. I think you should reconsider how easy it is to smoothly get an accelerated video buffer from a specific GPU component into an already heavily GPU optimized and dynamic web page. Web browsers have a lot more complicated graphics rendering problems to solve than VLC does.
- 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 ago
    Did 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 ago
      Yes, 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...

by sprash 7y ago

DCKing 7y ago

You're completely misunderstanding what this is about. Hardware video acceleration is not about rendering 3D graphics. 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, whereas it has been supported on Windows and Mac by almost all browsers for over a decade. The fact that this will be officially supported by a major browser vendor on Wayland first should tell you something.

sprash 7y ago
> Hardware video acceleration All video players on X11 have VDPAU support since ages. This is a Firefox specific problem which could be solved more easy on X11. > The fact that this will be officially supported by a major browser vendor on Wayland first should tell you something. It just tells me that Mozilla/Firefox really doesn't care about Linux because it took them 14 years since VDPAU works reliably on Linux to implement it.
- DCKing 7y ago
  Gnome Web, Midori, Falkon and Konqueror are browsers that only run on the "free" desktop, and don't support VAAPI/VDPAU either. Google built an entire OS based on Gentoo, and the desktop Linux build of Chrome doesn't support video acceleration either. I think you should reconsider how easy it is to smoothly get an accelerated video buffer from a specific GPU component into an already heavily GPU optimized and dynamic web page. Web browsers have a lot more complicated graphics rendering problems to solve than VLC does.
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 ago
  Did 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 ago
    Yes, 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...