Firefox 75 On Wayland Now To Have Full WebGL, Working VA-API Acceleration

[Britoid]

Subsurfaces are something else entirely. Just because they don't exist in X, doesn't mean dmabuf doesn't. I can only repeat - mpv uses dmabuf in the same way on X and Wayland. Of course that means mpv isn't using subsurfaces, but they aren't a necessity for zero-copy video.

What X compositors support dmabuf then?

[GrayShade]

No it is not. I realize this is a subjective opinion up to a point, but is not. I am writting this comment on Firefox right now having tens of tabs open, on Wayland, while a youtube video is playing on the background. I have no issue using Firefox/Wayland, right, now. If you do, well, don't use it. But saying it is "unusable" it is just FUD.

Are you using Gnome on Arch? Try full-screening that video.

[DanL]

Wake me when this supports X and VP9.

It be cool if VDPAU could also be supported.

Yeah, but I wouldn't hold my breath. There's always vdpau-va-driver and there's even a version that supports VP9 now: https://github.com/xtknight/vdpau-va-driver-vp9

[birdie]

Ignoring your trolling, this question has already been answered.

It's easier and faster under Wayland, which unlike X, isn't legacy technology.

X.org works everywhere, all the time, and supports 100% of GUI Linux applications nothing of which can be said about Wayland which is selective as hell and still has tons of issues. Not to mention it absolutely sucks in terms of remote desktopping - it's worse than Windows and X.org combined. And the fact that once a Wayland compositor crashes it brings down all the running GUI apps is just fabulous. Such a great tech we have here. Windows can perfectly run without DWM. X.org applications can perfectly run without a window manager.

MPV supports vdpau/vaapi under X.org perfectly. Don't tell me implementing those for X.org by Firefox would be difficult. They could have as well embedded mpv into Firefox - it's not like Firefox has its own libraries for audio/video decoding - it uses ffmpeg.

Yeah, I'm trolling. Try harder next time.

God, what a cesspool we have here. Fanatics upvoting fanatics.

[Gusar]

What X compositors support dmabuf then?

X compositors deal with X drawables - pixmaps to be exact. And they do so in a zero-copy way using the GLX_EXT_texture_from_pixmap extension, which was designed specifically for zero-copy composition. dmabuf-ing of the video data happens at a far lower level, way before X gets involved.

[brent]

What X compositors support dmabuf then?

All of them basically, because dma-buf and other buffer sharing stuff is handled inside Xorg. dma-buf is just a unified buffer sharing API, it's not magic. Zero copy buffer sharing has been possible for a really long time... much longer than dma-buf exists.

[Britoid]

X.org works everywhere, all the time, and supports 100% of GUI Linux applications nothing of which can be said about Wayland which is selective as hell and still has tons of issues. Not to mention it absolutely sucks in terms of remote desktopping - it's worse than Windows and X.org combined. And the fact that once a Wayland compositor crashes it brings down all the running GUI apps is just fabulous. Such a great tech we have here. Windows can perfectly run without DWM. X.org applications can perfectly run without a window manager.

Yeah, I'm trolling. Try harder next time. Stating facts nowadays is called trolling.

You're confusing so many things here.

1) They're KDE Wayland bugs, they don't exist in Sway, GNOME etc.
2) Right, and X crashing won't bring down GUI apps either?
3) Remote desktop is working fine here.
4) Windows is not comparable. It has a display system where it's normal that applications could loose access to the compositor (graphics driver updates etc), and applications don't usually talk it directly. Additionally, on newer versions of Windows it shouldn't be possible to run without dwm without crashing.

[Britoid]

X compositors deal with X drawables - pixmaps to be exact. And they do so in a zero-copy way using the GLX_EXT_texture_from_pixmap extension, which was designed specifically for zero-copy composition. dmabuf-ing of the video data happens at a far lower level, way before X gets involved.

Right, but applications can't directly share a dmabuf buffer with the X compositor, in the way FIrefox is doing here with the Wayland compositor (and using it with a subsurface)?

[brent]

Right, but applications can't directly share a dmabuf buffer with the X compositor, in the way FIrefox is doing here with the Wayland compositor?

Because they DON'T NEED TO. There are X-specific ways to share buffers efficiently. They may or may not use dma-buf behind the scenes.

[birdie]

1. KDE has major troubles working around Wayland which speaks volumes about Wayland APIs. It's not like KDE devs are stupid.

2. X.org has maybe crashed on me three times in my entire life. KWin and other window managers crash far too often and the system lives on. In Wayland a WM and a graphical subsystem are the same entity. That's absolutely wrong. Neither Windows, nor X.org was designed this way. How do you go about replacing your DM/WM in Wayland on the fly? Not possible at all?

3. Using experimental Pipewire? How fast does it work in comparison to ssh -X/RDP? Can you watch videos over poor connections? Can you pass-through OpenGL/any sort of HW acceleration? No, nothing? Oh, crap. Wayland works with raw rectangles made of pixels. It cannot even say which parts of an application need updates to be sent over the net and which don't. Each active application window needs to be encoded in its entirety and sent. Wow, such an utter crap.

4. Windows is always not comparable, only it offers vector very efficient GUI + video streams pass-through + Direct3D pass-through + audio compression and other perks. It was designed way before Microsoft even thought of remote desktopping yet they made it near perfect. Wayland designers perfectly got all the knowledge of the real world requirements and designed the protocol which is 100% ill-unsuitable for remote desktopping.

5. Wayland requires GUI APIs to handle raw output, scaling and font rendering and antialiasing as it does nothing itself. Let's say you have three applications running using three different APIs (Qt, Enlightenment, Gnome). Let's say the user wants to upscale all three or change font antialiasing for all of three. Wow, we have some crazy crap going on here as each GUI API has to independently implement these features instead of relying on one common API which does everything for them, e.g. Win32 or xlib (though honestly Xlib has long been abandoned and Xorg works in many ways close to Wayland nowadays since it wasn't designed to handle modern GUIs).

Wayland is great, isn't it? And this crap will forever require XWayland which is just nice. And XWayland applications cannot even properly interact with native Wayland apps. Tons of useful X.org utilities outright don't work under Wayland in any shape or form.

Yeah, I'm trolling hard.