2 ms·

> but I literally do run X without a compositor The price is tearing. Which may not be too noticeable at 1920@60fps, but playing a video on a bigger screen at

by kaba0 4y ago

> but I literally do run X without a compositor The price is tearing. Which may not be too noticeable at 1920@60fps, but playing a video on a bigger screen at higher refresh rate will very very seriously tear. It is not an accident that every other OS is compositor-only. > Wayland forces the display server, compositor, and window manager to be a single program Only the first two. You can allow a third-party program to control your windows’ state via any IPC mechanism you choose.

yjftsjthsd-h 4y ago
Sure, there are trade offs in skipping the compositor. But the claim was: > It is a display protocol, responsible for displaying things. A compositor is a must for that, it is not additional complexity at all. Which is just false; a compositor isn't a must unless you move the goalposts beyond "displaying things". > You can allow a third-party program to control your windows’ state via any IPC mechanism you choose. I guess you could, by adding a lot of API surface; has literally anyone ever done this, or is it just a hypothetical solution? Because I'm not aware of any existing compositor that lets you plug in a window manager.
- zozbot234 4y ago
  Wayland compositors have provisions for skipping the compositing part when a single client is running full screen. So, by your argument, Wayland is also "not a compositor".
  - yjftsjthsd-h 4y ago
    I don't think that follows. You can run a fully-functional X session, with an arbitrary number of windows, without any compositing. It's not some special case reluctantly added after people pointed out that the initial "you must fully double-buffer every single pixel every single time" wasn't actually universally a good idea. But even at face value... okay, so you'd like to extend the argument to say that not even Wayland actually forces you to composite? Because that's agreeing with my argument, just more strongly.

by kaba0 4y ago

yjftsjthsd-h 4y ago

Sure, there are trade offs in skipping the compositor. But the claim was: > It is a display protocol, responsible for displaying things. A compositor is a must for that, it is not additional complexity at all. Which is just false; a compositor isn't a must unless you move the goalposts beyond "displaying things". > You can allow a third-party program to control your windows’ state via any IPC mechanism you choose. I guess you could, by adding a lot of API surface; has literally anyone ever done this, or is it just a hypothetical solution? Because I'm not aware of any existing compositor that lets you plug in a window manager.

zozbot234 4y ago
Wayland compositors have provisions for skipping the compositing part when a single client is running full screen. So, by your argument, Wayland is also "not a compositor".
- yjftsjthsd-h 4y ago
  I don't think that follows. You can run a fully-functional X session, with an arbitrary number of windows, without any compositing. It's not some special case reluctantly added after people pointed out that the initial "you must fully double-buffer every single pixel every single time" wasn't actually universally a good idea. But even at face value... okay, so you'd like to extend the argument to say that not even Wayland actually forces you to composite? Because that's agreeing with my argument, just more strongly.