From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15650 invoked from network); 30 Nov 2020 12:29:12 -0000 Received: from ewsd.inri.net (107.191.116.128) by inbox.vuxu.org with ESMTPUTF8; 30 Nov 2020 12:29:12 -0000 Received: from MTA-08-4.privateemail.com ([198.54.122.58]) by ewsd; Mon Nov 30 07:22:52 -0500 2020 Received: from MTA-08.privateemail.com (localhost [127.0.0.1]) by MTA-08.privateemail.com (Postfix) with ESMTP id 77A6360044 for <9front@9front.org>; Mon, 30 Nov 2020 07:22:45 -0500 (EST) Received: from localhost (unknown [10.20.151.229]) by MTA-08.privateemail.com (Postfix) with ESMTPA id 601F660038 for <9front@9front.org>; Mon, 30 Nov 2020 12:22:44 +0000 (UTC) Date: Mon, 30 Nov 2020 04:22:29 -0800 From: Anthony Martin To: 9front@9front.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: decentralized extensible lifecycle plugin-aware scripting framework Subject: Re: [9front] /dev/draw performance Reply-To: 9front@9front.org Precedence: bulk hiro <23hiro@gmail.com> once said: > regardless i would love to hear the actual personal reasons. cause i'm > curious. and want to understand and learn from their vision, and > possibly a kind of pragmatism they applied that I still lack in this > regard. > > i am waiting for a good excuse. i asked for it on 9fans, but nobody > came to admit having written the code in the first place. > if you are on better speaking terms... there's lots of people like me > eager to listen to their answers. Ethan needs to quell his urge to opine on unfamiliar matters. Hiro needs to learn how to do basic research. To: 9fans@cse.psu.edu Subject: Re: [9fans] was 8=C2=BD slow and that lead to rio? From: "rob pike" Date: Wed, 30 Jan 2002 11:18:28 -0500 Rio was written for Brazil, in which the kernel had no graphics at all, and all graphical operations were done in user mode and then blasted as raw pixels onto the screen. That became untenable at low bandwidth, so when we put the draw operator in, the graphics functionality went back in the kernel as a stopgap. I hope it doesn't stay there, but it was an easy way to focus on the interesting problems. There are three reasons that rio doesn't multiplex the graphics: 1) history, as mentioned above; 2) speed; 3) to avoid the code bloat. Much of 8=C2=BD's source code involved grubbing around and rewriting graphics messages for the clients. This meant that the graphics code was scattered between library, kernel, and window system. Rio avoided all that gunk and doesn't need to change if the graphics interface changes, as it has a couple of times. It's a huge improvement. So the real answer is engineering, not performance. -rob What do I need to do? Anthony