The article author complains about some relatively minor details but completely misses the big picture.
I'm not going to talk about the availability and quality of the Wayland API, this was covered in other posts.
Here is what the decision looks like from the POV of someone building a product:
- Zoom is one of the few collaboration products which supports Linux with a native client. The native clients offer much better performance on every operating system.
- Some of the collaboration products (Zoom being one of them) implement 2 different codecs for the video streams and screen sharing. This is done to offer better performance, lower bandwidth, and better quality. For screen sharing the most important requirement is not which API is used, but if the text is readable.
- Zoom is a multiplatform product. All other platforms offer API for screenshots. Not all platforms have an API that captures the screen as a video stream. Using screenshots is the best way to cover all platforms.
- Collaboration products have high requirements for screen sharing: Capturing the entire desktop, capturing a single application, capturing a portion of the screen, excluding its own UI, etc. Support for multiple monitors, 4k, 5k support. Most of these use cases are not going to be covered by the Wayland API.
- This is a different use case than streaming your screen to twitch or youtube. Collaboration products have very low latency ( < 500ms). The presenter can change and any moment and clients can join at any time and they expect the screen-sharing stream to start immediately.
- Zoom supports h264 as their main codec. API which provides VP8 will require contradicting and encoding which will slow down the performance.
- Even if the video stream coming directly from the screen didn't require transcoding, it is still required to do a post processing. For screen sharing (with no video on the screen) it is wasteful to generate too many frames.