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.
> 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__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/l...
[3] X Render Extensison, section 8 https://www.x.org/releases/current/doc/renderproto/renderpro...
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-ac...
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.
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.
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.