From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 9427828BBA for ; Mon, 5 Aug 2024 13:52:34 +0200 (CEST) Received: from crocodile.elm.relay.mailchannels.net ([23.83.212.45]) by 9front; Mon Aug 5 07:51:34 -0400 2024 X-Sender-Id: dreamhost|x-authsender|lists@ecloud.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 44E545C4EC9 for <9front@9front.org>; Mon, 5 Aug 2024 11:51:32 +0000 (UTC) Received: from pdx1-sub0-mail-a312.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DE9515C4972 for <9front@9front.org>; Mon, 5 Aug 2024 11:51:31 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1722858691; a=rsa-sha256; cv=none; b=Eer9PEnuTtEJHX3mRpHt4YGovNcO4EvKHTWiI7cwYlTIJT4SERWUfVVBlHmwHEs/GpoGfm gbf+UPjHXBhPV4CR/cfMgO3NgUGF6RhiBFH5j2j3RBryLiJRU1dKk4fGN0dL9xs/7ycKzC cZdUZwYKZInC5Y0qKec6o0VJf5PBFd3gbuMnH31s5mQrTootT75rsthivQPRpP3Vgy4h5a U//P19JUD75oyws5H9ISG85kJVKGnBNXBJQ91Tnfpnszf+iXqdMJfL7EZYl9btpdm1wqn+ ZJ2jpz2/GlGEBNnK1RXp8aCEIrmHUfQI9ftwyzr5Us0rv40iWplo1EnFudrGMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1722858691; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=X3MvGz21plyQWDOk+RvSZ/hHXAGMYEkReLVUkgCu/9c=; b=S4aMuaRUhwyLQBAz/4Uz6kMIqTzu8699YHwrpQfbTscRiwmO3mVi4XohJ6Ib3Rp3e/Bjbr lnPpIO733j/w9DRdHrmigVhzdQQop7JquAxDMVmbgC1Ztd1Bw7irXPGrKmMuRQJDtZgtlA JxhJOLP6WTVa3x0KwzAuPYXwgn5M4QTEdRJuBAJnF7MK6mCxyjC2oUxvcyuQy1xQzFNEws ntZf01vn5Za5nXX97YV9aAfcw0F7JAzHvLzREYEggPrZTbfPejRSEh1HGMs7L6OQtrtHCa YPMXA87htVh9mcpAjw+v4Wsm99c7+ldhvgKjn2wvzufoVbTmXTXIj1m8ZOGeUA== ARC-Authentication-Results: i=1; rspamd-6777b474b8-snhg6; auth=pass smtp.auth=dreamhost smtp.mailfrom=lists@ecloud.org X-Sender-Id: dreamhost|x-authsender|lists@ecloud.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|lists@ecloud.org X-MailChannels-Auth-Id: dreamhost X-Reign-Turn: 4458fc5920bac261_1722858692119_3700641327 X-MC-Loop-Signature: 1722858692119:269835092 X-MC-Ingress-Time: 1722858692119 Received: from pdx1-sub0-mail-a312.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.100.20.112 (trex/7.0.2); Mon, 05 Aug 2024 11:51:32 +0000 Received: from black (unknown [87.200.89.58]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: lists@ecloud.org) by pdx1-sub0-mail-a312.dreamhost.com (Postfix) with ESMTPSA id 4Wcvsv18P5zJZ for <9front@9front.org>; Mon, 5 Aug 2024 04:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecloud.org; s=dreamhost; t=1722858691; bh=X3MvGz21plyQWDOk+RvSZ/hHXAGMYEkReLVUkgCu/9c=; h=Date:From:To:Subject:Content-Type; b=nHrM5AAvSgljaCX+IZCUXzBqyrSKxXQHIP8/+bAO67Suny8j6D+qbjBm4AucjzFWr ZFHxz6GFwT6fwDGY8Uaq08ApeWxEyab+1Wmjcxf9gvU7G6uLveb27xM/B3k0yXjM/o r6oKZCFEO8gXiltgCSVGEE97NPQQ61MaIonaRlBIVyWfZzoUvdevd4rEi7Cn3mHNiv Vgwul7YuRmwloaf/lzhYSONACS4EsT28F6R14sotjwCwBQHIMBj/t65CegFSAXurDG yDo8+i04HBYbN4KOIM3irhAOvsBshmeUUExEfDdthC2xV4nJcClkF3N5iZADlOTTHM 8SYAPgdCEOkeA== Date: Mon, 5 Aug 2024 13:51:26 +0200 From: Shawn Rutledge To: 9front@9front.org Message-ID: <20240805115126.rm47l4ifx7rrwgtx@black> References: <6FB99C7720140A4B3969EA601A4B3588@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtualized strategy hardware Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk On Mon, Aug 05, 2024 at 10:02:10AM +0200, hiro wrote: > > In that respect, it's strictly a worse fit for Plan 9 than X, which at > > least is designed with networking in mind, I suspect? > > Both Plan 9 and X are designed with networking in mind. > > > Though, there is a tool for networking transparency on Linux with > > Wayland, so it's not impossible. > > I bet they are multiplexing all graphical output as a lossy video stream. > Careful design from the ground up on the remote protocol level is > needed to solve the problem in a lossless, bandwidth-efficient, and > roundtrip-reducing way. And then all applications using the protocol > have to use it in the right way and not try to sabotage all the > efforts that got put into this mechanism: modern x11 programs suffer > from the same problem that wayland does, kde/gnome/google/mozilla et > all started to use x11 inefficiently, introducing bad > round-trip-sensitive implementations for unimportant cosmetic features > like animations. Yes that's an old problem. One place where I worked over 20 years ago, the boss had set up dual networks: one for internal stuff and one for the Internet. He had a pile of surplus NCD X-terminals, which he made us use for Internet stuff, running the actual programs on a shared Sun machine: so fully remote over 100mbit ethernet. (Of course he was also routinely spying on us to make sure we didn't waste too much time web-surfing or socializing.) It quickly became clear which programs were efficient that way and which weren't. Qt and GTK were both already trying to render the whole UI into one window, doing widget compositing themselves; I think this explanation here is from that time period (and offers workarounds): https://doc.qt.io/qt-6/qwidget.html#native-widgets-vs-alien-widgets That just made them feel much slower under such conditions, because often the buffer for the whole window had to be resent. (VNC works better than that, because of tiling.) But the tradeoff is if each widget generates resources on the X11 server side (which in this case had a rather small amount of memory, a few megabytes), there is a limit to how complex the UI can be (so you are stuck either way; even using too many colors was expensive on those terminals). And the window-per-widget architecture is slower in the more common case where the X server is on the same machine where the application runs, shared memory is possible, and you might even have a GPU. Don't trust the X server to be the quickest way to render your 2D stuff: do it on your own if you want to be sure that it's as quick as it needs to be. Plus, AA really benefits everyone, and https://en.wikipedia.org/wiki/X_Rendering_Extension is only for fonts, not for arbitrary graphics. (Same problem as on Plan 9. Should we blame Keith Packard for not going further than just font rendering?) There's no way to have AA in arbitrary 2D graphics rendered on the X server, AFAIK. So basically the widget toolkits gave up on supporting efficient networked X11 ages ago, and not for completely frivolous reasons. There were only a few users, maybe not vocal enough. Not sure what's the state-of-the-art toolkit that is actually good at it, though. TK was ok, as I remember. (The work itself at that company was interesting: on the upside, where else could I have been paid to write Scheme full-time for a year? I still use Scheme now because of what I learned there. And I was working on remote-UI stuff there too. But got fed up with the low pay and control-freak attitude, and left as soon as I got a better offer.) Anyway the toolkits got away with that on X11, which maybe contributed to the assumption that shared memory is fine for Wayland as well, and remote-desktop use cases are a niche case that can be served with things like VNC, RDP, and video streaming. The KDE/Plasma project is pursuing all of these, by the way. There's pipewire.org which I got the impression was for audio first, and then got video shoehorned in as well. Accordingly there's https://invent.kde.org/plasma/kpipewire ...not that I've tried it. And https://conf.kde.org/event/5/contributions/133/ ... that one surprised me, because I thought RDP is a complex Microsoft beast. Seems like a lot of work to support that in open source. But if video streaming is the solution, it seems to me an assumption is being made that the server (where the applications run) has a GPU then: it would help for rendering the applications (with AA, blending, animations and all), and it would help for video compression too. Somewhat of a break from tradition then. I agree that a solution designed specifically with low bandwidth and low latency in mind ought to be better. But is 9p really for that? I'm trying to work that way; time will tell...