3 ms·

For my personal taste it's already a mess but for the the average masochist it's maybe bearable. The real mess starts from here though: - Wayland can not rende

by sprash 3y ago

For my personal taste it's already a mess but for the the average masochist it's maybe bearable. The real mess starts from here though: - Wayland can not render strings. You need something external just to render some other text than "hello world". And depending on the library text rendering will look different for each application. - Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely. - If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor.

chlorion 3y ago
To me these are all advantages, not disadvantages. Wayland is not X11 and doesn't want to be, it doesn't implement even a fraction of what X11 did and that is an intentional design choice! Wayland does not provide any graphics drawing primitives at all. It only sets up a handle to some shared memory and expects the client to do all drawing. I think the point here is that you shouldn't be using the display protocol to render text in the first place. If you want to draw text you use a library that is designed for that task rather than shoving that functionality into the compositor and into the Wayland protocol itself. >- Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely. You don't have to use a thread to do this! You aren't forced to block and wait for the callbacks, you can implement your own event loop and check for messages when you want to! >- If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor. I think it's good that clients can't capture the screen without permission, and I think using dbus for IPC is very reasonable, but I don't know anything about pipewire or the compatibility stuff. Also I think it's fair to not like some of these design choices for sure, but it would probably be better for people who like X11's design to continue to use X11 rather than trying to force Wayland into an X11 clone. X11 will be around for a very long time so I don't think anybody will be forced to stop using it any time soon, and people can pick it up if development stops!
vetinari 3y ago
> Wayland can not render strings. Wayland is a display server. Display servers in general do not render strings. They render bitmaps passed in by the clients. Clients are welcome to use their favorite string render libraries into those bitmaps. > Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. Do you realize that all wayland calls are async? On the client side, you don't have to block on waiting on empty socket, if you do not want. Few conmmens above, someone complained that a basic wayland client is complicated. The complicated thing was... setting up an event loop. > If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. Yes; but these dependencies are in different processes, not yours. From the POV of your process, it is just an structured IPC. XGetImage() is not that simple; it only coincidentally worked due to implementation detail. Having a global framebuffer is not mandatory, just at the time all the PCs had it. Nowadays, even PC hardware is getting overlays, so there might not be a buffer that represents what's on the display anymore. Another issue is, that it is impossible to implement zero-copy screen casting with XGetImage(). It is possible and has been done with wayland and dmabuf, feeding the screencasted surface into hardware video encoder (without the buffer bouncing between system and GPU ram several times), and the userspace getting already compressed video stream. Final issue is, that XGetImage() is not gated via user permission and does not provide indicators, that the screen was grabbed or is being casted. Wayland does.

by sprash 3y ago

chlorion 3y ago

To me these are all advantages, not disadvantages. Wayland is not X11 and doesn't want to be, it doesn't implement even a fraction of what X11 did and that is an intentional design choice! Wayland does not provide any graphics drawing primitives at all. It only sets up a handle to some shared memory and expects the client to do all drawing. I think the point here is that you shouldn't be using the display protocol to render text in the first place. If you want to draw text you use a library that is designed for that task rather than shoving that functionality into the compositor and into the Wayland protocol itself. >- Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely. You don't have to use a thread to do this! You aren't forced to block and wait for the callbacks, you can implement your own event loop and check for messages when you want to! >- If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor. I think it's good that clients can't capture the screen without permission, and I think using dbus for IPC is very reasonable, but I don't know anything about pipewire or the compatibility stuff. Also I think it's fair to not like some of these design choices for sure, but it would probably be better for people who like X11's design to continue to use X11 rather than trying to force Wayland into an X11 clone. X11 will be around for a very long time so I don't think anybody will be forced to stop using it any time soon, and people can pick it up if development stops!

vetinari 3y ago

> Wayland can not render strings. Wayland is a display server. Display servers in general do not render strings. They render bitmaps passed in by the clients. Clients are welcome to use their favorite string render libraries into those bitmaps. > Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. Do you realize that all wayland calls are async? On the client side, you don't have to block on waiting on empty socket, if you do not want. Few conmmens above, someone complained that a basic wayland client is complicated. The complicated thing was... setting up an event loop. > If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. Yes; but these dependencies are in different processes, not yours. From the POV of your process, it is just an structured IPC. XGetImage() is not that simple; it only coincidentally worked due to implementation detail. Having a global framebuffer is not mandatory, just at the time all the PCs had it. Nowadays, even PC hardware is getting overlays, so there might not be a buffer that represents what's on the display anymore. Another issue is, that it is impossible to implement zero-copy screen casting with XGetImage(). It is possible and has been done with wayland and dmabuf, feeding the screencasted surface into hardware video encoder (without the buffer bouncing between system and GPU ram several times), and the userspace getting already compressed video stream. Final issue is, that XGetImage() is not gated via user permission and does not provide indicators, that the screen was grabbed or is being casted. Wayland does.