> Low network utilization yes and perhaps superior to X11 core protocol, but it doesn't come for free, for example in terms of latency.
You can have your cake and eat it too: You can disable the compression if it's a problem. It's highly configurable if you want to play with it.
The compression means trading a little bit of hardware resources at either end for a better UX (lower latency, higher throughput).
> The higher the window size the higher the requirements for the encoder (though Waypipe does say "This way, Waypipe can send only the regions of the buffer that have changed relative to the remote copy.", or is it talking about the video encoder?).
The core wayland protocol mandates communicating which parts of a "surface" (read: window) has changed when a new buffer is submitted in a "surface commit". Neither a compositor nor waypipe will do anything if nothing has changed.
> I also think that just "forget about it, we'll video stream it" is just giving up on the problem altogether.
Each surface has its own stream, and is updated independently. E.g., a video player on a webpage will generally be a subsurface, a context menu or plugin is a popup surface. They're all processed independently, with each their own damage tracking (and if applicable, video compression). If content is stretched or scaled up, only the original source buffer will be transmitted, allowing the display server to take care of this.
This is not giving up, this is the maximum effort, optimal implementation.
> I just fondly remember the times when (possibly two decades ago) I run ... over a 100Mbit network
For reference, a single 4k 60Hz display takes ~15Gb/s to keep fed with bitmaps. Even a quarter of the screen takes 3.7Gb/s. Not even cinematic refresh rates would be able to fit within a 1Gb/s line.