Sure. But imagine some piece of exotic hardware, e.g. computer mouse, that reports its movement at 1000Hz.

If the compositor wants to notify the client as soon as possible, it has to send 1000 messages per second. If you buffer them, you're wasting the hardware's potential, if you don't buffer, them you're doing 1000 write()s per second, which is... ugh.

If you're literally going to design the protocol from scratch and require all existing software to deal with it, why not pick the IPC model that doesn't have this issue.

▲

mort96 6 hours ago | parent | next [-]

Wait how do you solve that with shared memory command buffers? Don’t you need to involve the kernel to notify the receiver that you’ve written stuff to the command buffer?

Or would the receiver spin in a tight loop on a memory load from some byte in shared memory which indicates a new buffer is submitted, so that it gets notified without involving the kernel? Or is there some fancy mechanism I’m not aware of?

▲

nananana9 6 hours ago | parent [-]

You most likely already have a tight loop lying around - the compositor needs to composite the screen each frame, you can probably poll in there. The client likely has one too, if not, you can involve the kernel & scheduler. If you need super high precision you probably busy wait, I don't know what the Linux scheduler's resolution is.

I would probably expose a poll() and let the client deal with it, I don't know if there's a one-size-fits-all signaling mechanism. But you have control over it, which is probably another plus.

	▲	mort96 6 hours ago \| parent [-]
		Those loops aren’t tight, they sleep for like 10-16ms for live windows or much longer for background windows. You were talking about receiving updates at 1000Hz.

▲

simonask 4 hours ago | parent | prev | next [-]

Just to let you know, 1000 messages per second over a UNIX socket between two processes is very much well within the capabilities of any recent machine running, say, Linux. That’s not many at all.

▲

simoncion 5 hours ago | parent | prev [-]

> But imagine some piece of exotic hardware, e.g. computer mouse, that reports its movement at 1000Hz.

Speaking of... it looks like common Wayland compositors [0] still kill clients that can't keep up with "high speed" event generators like 1kHz mice. [1] So, that's nice.

(For people who plan to retort with "just handle events in a timely manner", check out the comment here [2]. OSX, Windows, and X11 all cope just fine with programs that go unresponsive for multiple seconds. If the statements in this bug report (and the reports I've read elsewhere) are accurate, Wayland doesn't... and that is inexcusable.)

[0] ...or whatever the Wayland terminology is for the thing that does the work of the X11 compositor + window manager...

[1] <https://gitlab.freedesktop.org/wayland/wayland/-/work_items/...>

[2] <https://gitlab.freedesktop.org/wayland/wayland/-/work_items/...>