Does anyone have a grasp/understanding of how desktop environments work on Linux? I don't. For me, everything feels to get more and more convoluted and tacked on.
Instead of cutting its losses early and dumping X11, both the Unix vendors and open source spent far too long trying to make lemonade out of a truckload of rotten lemons. And that’s why Linux GUIs are so far behind.
It’s notable how rapidly Apple was able to evolve their Unix GUI because they were not tied to X11 and instead embraced the integrated model, even designing their own GPUs nowadays.
GNOME is probably the most polished in terms of aesthetics, animations, and gestures. The downside is that it’s much more a tablet OS experience with a few desktop affordances — kind of like iPadOS if it were turned into a desktop OS — than it is a traditional DE. As such expect for various power user features to be diminished or absent compared to macOS or Windows. Pantheon also ranks highly here, with similar limitations.
KDE comes in second. Compared to GNOME it still has a number of rough edges in terms of aesthetics but is comparable to Windows in terms of overall capabilities and design.
Third would be Cinnamon, which attempts to blend a more Windows-like desktop with GNOME-like polish, but last I knew this project is understaffed which has resulted in it falling behind a bit. Also requires X11, unlike GNOME and KDE which work well with Wayland.
Trying to separate X from the client/server model would be like saying: "I like Unix just fine, except files and processes and the shell and the software tool philosophy, really." — You just don't have much left.
I also disagree that the client/server design is a problem. Modern graphics hardware is remote from the CPU for all intents and purposes. So remote buffer manipulations protocol is exactly what is needed.
But, a few days ago, I finally switched over, on a modern machine (~ 6 months old), with a modern OS (more than modern -- I'm running a pre-release version). And now, finally, I see what all the fuss is about. Wayland is absolutely beautiful. The rendering and animations are gorgeous, and so so smooth. The whole system is far faster, far more robust, and far more efficient both in computing resources and workflow than anything I was ever able to achieve on X.
I have been using Linux on X11 displays as my primary machine since 1996. I do development work, but not with graphics, where I'm just a regular user. I don't really care about how good the design is or how hard it is to write programs using X / Wayland / whatever. All I care about is how usable my system is. And for me, having reached the Wayland promised land, I now understand what I was missing with X, in a way that I could never have before.
Tear-free rendering, all the time, every time. Frame perfect windows, all the time, every time. A desktop that finally feels immediately responsive, all the time, every time. Under X11, all those round trips to and from the X server add milliseconds to response time, hard to benchmark, but very easy to feel. Worse yet, X11 responsiveness is variable. If the system is loaded, your desktop can lag so badly under X. This doesn't happen with Wayland.
I now have OSD volume controls that work even when the screen is locked. This was never possible with X, and can never be possible.
I now have a lockscreen that, guaranteed, will not leave my desktop unlocked if someone crashes it by feeding it malicious input. X11 is architecturally incapable of providing such guarantees. There were several instances of security bugs where lock screens in X11 crashed in exactly this way.
Wayland has now reached the point where it is a must-have for me. If it doesn't run Wayland, I won't buy it, and I won't install it. Yes, X11 works well after all these years, but Wayland is enjoyable to use in a way that X11 never was.
There are some old applications on Windows that aren't DPI-aware and look weird, but usually fixable. It's still a million times better than whatever X11 does.
IMO macOS is the only OS where graphics and fonts work the exact way one would expect reliably.
The rest, not so much. Applications work only if they do the right thing. Applications could do the right thing on X11 too. They don't just like the "old" applications on Windows.
Anyway, you've dragged this away from the general points: issues with Linux GUI toolkits have little to do with XWindow, and Apple's GUI toolkits have had to evolve just as the Linux ones have.
I've hard-coded some DPI settings for certain apps that I always display on the same monitor.
Meanwhile, I have zero issues with the same pair of monitors on Windows and macOS. I daily drive all 3 of them.
I disagree. Other platforms did similar things where clients would command the OS what it should draw and the OS would handle all app's rendering which allowed for good performance on primitive hardware. Like other display severs X did evolve to also be for passing around framebuffers of what the app drew once hardware became capable. X's problems come from being hard to maintain, being a monolith of unrelated concepts, having poor security, etc.
Apple rapidly evolved their GUI because they are trying to support just the one. And, frankly, they are starting to buckle on the idea that they are fully coherent.
Direct3D on Windows: app renders something and calls IDXGISwapChain.Present. The implementation communicates with the desktop compositor running in the dwm.exe process, dwm.exe renders the entire desktop composed of multiple windows, then communicates with physical GPU to wait for next vertical blank event.
Bare metal Linux with DRM: app renders something, calls drmModePageFlip(), then waits for next vertical blank event with poll() and drmHandleEvent() functions. Embedded Linux developers did an amazing job about DRM/KMS, in my experience the API is both reliable and efficient.
X Window systems have multiple different methods, glXSwapIntervalEXT, glXSwapIntervalMESA, glXSwapIntervalSGI, but in practice none of them is reliable, and on some systems none of them is even supported. Unfortunately, this makes rendering tear-free 3D content on X11-based desktops hard-to-impossible.
Hardware accelerated 3D graphics is the best way to render pretty much everything on modern hardware, games or not games. High-resolution displays are omnipresent. Even cell phones often have FullHD or more pixels, like 2796×1290 or 2556×1179 in the iPhones.
https://learn.microsoft.com/en-us/windows/win32/direct2d/com...
Specifically, WPF is based on DirectX 9, Direct2D is based on Direct3D 11, UWP and WinUI are based on Direct2D. On my computer, both Chromium and Firefox browsers are using Angle on top of D3D11, Firefox uses Direct2D for canvas only.
Also, even legacy apps who render their GUI with GDI are still using 3D GPUs to an extent. Some GDI operations like BitBlt are accelerated internally by the OS. And the OS composes windows on the desktop with D3D11, dwm.exe process does that.
A counterexample is video playback. The best way for video is to use the hardware decoder and hardware compositor. You don't want to render the video texture to a quad. Using the hardware compositor requires less computation and less power than using 3D graphics.
Not according to Microsoft, see that page https://learn.microsoft.com/en-us/windows/win32/medfound/how...
Microsoft strongly recommends that new code use MediaPlayer or the lower level IMFMediaEngine APIs to play video media in Windows instead of the EVR, when possible. Microsoft suggests that existing code that uses the legacy APIs be rewritten to use the new APIs if possible.
That lower level IMFMediaEngine API they recommend for Win10+ delivers uncompressed video frames in D3D11 textures.
Which in the best case is done via hardware decoding as I said.
The composition is done by the 3D GPU like I said. Either in your app if you render that video yourself, or if you supply a swap chain’s back buffer to IMFMediaEngine.TransferVideoFrame method, dwm.exe will do it.
That’s how modern Windows does that in practice. Everything does go through the 3D graphics pipeline, and starting from Win8 it’s impossible to disable.
I’m not even sure modern PC hardware supports these hardware layers, except for one small extra layer for hardware mouse cursor. On my computer D3DCAPS_OVERLAY and DDCAPS_OVERLAY flags are unset. The driver reports to the OS the hardware doesn’t support any hardware overlay surfaces.
Yes, they do. I'm guessing you may be using an older nvidia gpu. In the case no overlay is available the video can become fullscreen and to take the only layer from dwm. For pcs the benefit is less about performance / power and more about lower latency.
Why are you so certain?
> you may be using an older nvidia gpu.
Tested AMD Vega 7 inside Ryzen 5 5600U, and nVidia 1080Ti — dxcapsviewer.exe shows the same result, no overlays are supported. Only the D3DCURSORCAPS_COLOR hardware cursor is there.
> the video can become fullscreen and to take the only layer from dwm
Indeed, exclusive D3D full-screen mode allows to bypass dwm.exe compositor, even on modern Windows. But I don’t think it’s evidence of any hardware composition being used.
Look at documentation from GPU manufacturers, look at GPUs that support multiplane overlay on windows.
>But I don’t think it’s evidence of any hardware composition being used.
It's not, but it doesn't require using 3D graphics to put the texture on the display.
According to Microsoft, MPO is an optional feature: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
According to random people on the internets, the feature is broken for both nVidia and AMD: https://www.reddit.com/r/AMDHelp/comments/yr5dda/can_someone...
nVidia agrees and recommends disabling MPO with a registry setting: https://nvidia.custhelp.com/app/answers/detail/a_id/5157/~/a...
> it doesn't require using 3D graphics to put the texture on the display
In practice, 3D graphics is the best way to put pixels on the display. At this point, I believe other ways are remnants of the old GPUs which had 2D blitting hardware.
I’m curious to see how much of an impact the wayland architecture will be, and if ‘gnome only’ apps become a thing.
Sidenote: I hacked the wayland protocol implementation for gnome into working at least for SteamVR, but at least with AMD gpus there is some serious bug preventing the card from performing properly. It basically throttles itself for no reason and never hits the refresh rates needed for smooth VR, especially since there is no asynchronous reprojection at the moment. So while ideally the drm-leasing problem would be solved already there are other even more important problems to solve with linux VR for now.