3 ms·

The biggest problem of Wayland is that it has the wrong philosophy ("Every frame is perfect") and the wrong abstractions ("Everything in the universe is an arra

by sprash 5y ago

The biggest problem of Wayland is that it has the wrong philosophy ("Every frame is perfect") and the wrong abstractions ("Everything in the universe is an array with RGB values"). If your foundations are flawed like that no "slowing down", "specification writing" or "focusing on improving your protocol" as suggested in the article will help. You are doomed from the start. What remains is a very expensive and cumbersome way of blitting bitmaps.

kaba0 5y ago
? Philosophy-wise, I don’t see how having “most frames are perfect” any better. We are talking about a soft-real time compositor whose only purpose is putting correct images to the monitor(s). And Wayland supports plenty of formats for bitmaps, not sure about what you mean by your “wrong abstraction” thing. The only requirement is that both the client and server should know the given format, but there is proper “hand-shaking” about it.
- sprash 5y ago
  The Philosophy is completely wrong on many levels. On one level for some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames. Also displays have different pitch values, subpixel arrangements, color spaces, etc. A line from A to B might look completely different on different monitors. By offering only RGB arrays as abstraction Wayland pushes the the need for care of those differences down to clients which is a mistake. On another level a Desktop system in general is much more than a bunch of bitmaps blittet together. Applications need to interact and such functionality has to be tightly integrated into the compositor with standardized protocols otherwise it will be impossible to have such functionality. As example I recomment implementing a native Wayland client that takes screenshots and works on every compositor (Impossible because something as essential as taking screen dumps is not even part of the core protocol).
  - kaba0 5y ago
    > On one level for some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames. There are protocols to circumvent frame syncing for the rare case it is needed, so it is solved. And as I already said, it doesn’t offer only RGB arrays as abstraction. Yeah, color management can be made better (there is ongoing work regarding that), but the protocol is extendable so it’s more of a when question, not an if. And it’s not like X solved it. And about the screenshot: the problem here is that they want to create a good API for that. It should be pipewire-based in the opinion of gnome devs, and wayland based in case of wlroots. The actual problem is more difficult than “dump all the pixels”. And even if no agreement happens, the protocol allows for querying available protocols so a cross-DE screenshot app is entirely possible.
  - Avamander 5y ago
    It'll take another Poettering to bring Linux well-working VFR, HDR and good color-management. The same cycle of Pulseaudio and systemd is repeated. People will certainly loathe, The Replacement and the replacers are certainly quite arrogant and makes new mistakes, but The Old One and the old ones even more so. Toes are stepped, epic forum threads are written. But in the end The Replacement ends up as the dominant solution and others maybe limp to catch up, maybe not. After a decade or two, a New Implementation appears that finally learns from the mistakes of both The Old One and The Replacement. Users have gotten what they need, rejoice!

by sprash 5y ago

kaba0 5y ago

? Philosophy-wise, I don’t see how having “most frames are perfect” any better. We are talking about a soft-real time compositor whose only purpose is putting correct images to the monitor(s). And Wayland supports plenty of formats for bitmaps, not sure about what you mean by your “wrong abstraction” thing. The only requirement is that both the client and server should know the given format, but there is proper “hand-shaking” about it.

sprash 5y ago
The Philosophy is completely wrong on many levels. On one level for some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames. Also displays have different pitch values, subpixel arrangements, color spaces, etc. A line from A to B might look completely different on different monitors. By offering only RGB arrays as abstraction Wayland pushes the the need for care of those differences down to clients which is a mistake. On another level a Desktop system in general is much more than a bunch of bitmaps blittet together. Applications need to interact and such functionality has to be tightly integrated into the compositor with standardized protocols otherwise it will be impossible to have such functionality. As example I recomment implementing a native Wayland client that takes screenshots and works on every compositor (Impossible because something as essential as taking screen dumps is not even part of the core protocol).
- kaba0 5y ago
  > On one level for some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames. There are protocols to circumvent frame syncing for the rare case it is needed, so it is solved. And as I already said, it doesn’t offer only RGB arrays as abstraction. Yeah, color management can be made better (there is ongoing work regarding that), but the protocol is extendable so it’s more of a when question, not an if. And it’s not like X solved it. And about the screenshot: the problem here is that they want to create a good API for that. It should be pipewire-based in the opinion of gnome devs, and wayland based in case of wlroots. The actual problem is more difficult than “dump all the pixels”. And even if no agreement happens, the protocol allows for querying available protocols so a cross-DE screenshot app is entirely possible.
- Avamander 5y ago
  It'll take another Poettering to bring Linux well-working VFR, HDR and good color-management. The same cycle of Pulseaudio and systemd is repeated. People will certainly loathe, The Replacement and the replacers are certainly quite arrogant and makes new mistakes, but The Old One and the old ones even more so. Toes are stepped, epic forum threads are written. But in the end The Replacement ends up as the dominant solution and others maybe limp to catch up, maybe not. After a decade or two, a New Implementation appears that finally learns from the mistakes of both The Old One and The Replacement. Users have gotten what they need, rejoice!