3 ms·
On a modern computer, programs that wish to draw on the screen do not interface with the hardware directly (aside from games). Instead, they communicate with an
by dTal 3y ago
On a modern computer, programs that wish to draw on the screen do not interface with the hardware directly (aside from games). Instead, they communicate with another program that does the drawing on their behalf. This other program is called a "display server", a GUI program such as Firefox is a "client", and the details of the mechanism by which they communicate is called a "protocol".
Until recently, "Xorg" was the main centralized implementation of a display server on unix-likes, and any program wishing to display graphics had to speak its native protocol, "X11". Now many systems run display servers which speak a new protocol, "Wayland"[note]. While a compatibility shim does exist (XWayland), ideally a program wishing to display graphics on such a system should do so using the new protocol directly, for better performance and features.
Porting an application to a new graphics backend obviously requires some effort and testing. Until now, out of an abundance of caution, Firefox simply spoke the old X11 protocol by default, even when running on a new Wayland system, relying on the XWayland compatibility shim. Now Firefox is essentially announcing that they believe their Wayland backend is robust and complete enough to enable by default.
I hope this helps!
[note] the nature of Wayland is such that there are many implementations of such servers, not just one main one like with Xorg. This is because the semantics of the Wayland protocol have taken over some of the functions previously handled (on X11) by a separate piece of software, called a "window manager", which contributed heavily to the look, feel, and behavior of a particular desktop GUI. Thus, while Xorg was agnostic and could be shared by different GUIs, with Wayland each GUI system must implement its own display server.
- kruuuder 3y agoThank you!
- charcircuit 3y ago>This is because the semantics of the Wayland protocol have taken over some of the functions previously handled (on X11) by a separate piece of software, called a "window manager", which contributed heavily to the look, feel, and behavior of a particular desktop GUI. Window managers can be separate with Wayland too. It just seems like the Wayland people don't want to unify under one implementation and have separate window managers.
- yjftsjthsd-h 3y agoIn practice, I'm not aware of anyone trying to write a compositor for wayland that doesn't include the window manager (other than xwayland, I guess).
- LoganDark 3y agoThis is because unifying the display manager, compositor, and window manager allows for each implementation to be far more integrated. For example, this opens up the door to virtual-reality or mixed-reality Wayland display managers, that can run desktop apps without the usual overhead of screen capture. Xorg can't do that. Trying to make Xorg do that will only end in misery.
- charcircuit 3y agoBeing much more integrated isn't actually that valuable. VR compositors already render a full screen frame that goes straight to the display. The window manager for VR is typically in a separate process from the compositor. You could add Wayland support to an existing VR compositor, but that wouldn't force you to combine the window manager into the same process.
- LoganDark 3y agoExcuse me, but try to actually use any VR window manager, today, on an OS like Windows. It will bog down and eventually crash your GPU when you open too many windows, because it has to capture those windows from the regular desktop. A Wayland display manager on Linux would not have this issue, because it would already be the window server, so it wouldn't have to perform any extra captures. I only know about this because I have experience trying to do this exact thing.
- charcircuit 3y agoWayland would have the same exact problem as you described if it was implemented by copying a window's surface to the surface you are submitting to the compositor. The solution in both cases is to just submit the original surface to the compositor. >I only know about this because I have experience trying to do this exact thing. Did you use Windows Mixed Reality? If you want deep integration with the operating system, you should use the implementation that is part of the operating system.