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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30040 invoked from network); 30 Nov 2020 14:14:25 -0000 Received: from ewsd.inri.net (107.191.116.128) by inbox.vuxu.org with ESMTPUTF8; 30 Nov 2020 14:14:25 -0000 Received: from mail-ej1-f51.google.com ([209.85.218.51]) by ewsd; Mon Nov 30 09:10:09 -0500 2020 Received: by mail-ej1-f51.google.com with SMTP id a16so22060755ejj.5 for <9front@9front.org>; Mon, 30 Nov 2020 06:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=liMI/177RM9c2iSVvXErRWYTw4E+BD6oqSJzG1zo/tA=; b=M1idufEXzHZQzPkNauHXiFWzvp2b1it6ksNTzZRcgRU8a3LRMIAFv3FpyMH4oUnSJF kBrumgb7JEW2Fr1k4q4LHQpTNG3dSbYgW2WKBKYIsUhG2aSY9x4vCwvxemFzHuVIaxXX LGA6BlZPUQ6KadPO/xanxEAN9g4uel/KqyIDsQeoFtaHzhshVr5QgbyQYfRNAoeu5KNj axDBvRUohGr8JUqlA6wFyAfI9UzqoCiC8GxZLt1ZxEWg82Kmsk2ZJGZBU5yNS388U5IZ hLJPhEAqumnipp+3rcIS/9mdrbPaKbNqLcAVUbzTxb+N88OkPMQ18Tl9Fx+FHJuWe2nA lKkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=liMI/177RM9c2iSVvXErRWYTw4E+BD6oqSJzG1zo/tA=; b=OzSv0+VHiMIqKyMJ+HDiAhVXBon9JoNIrTTFu1oQflrBbtQZrimxfmkaUahFSR5Uex kdmOXpZTIR7T9tH0nHCT5ToyO8vuVdqKYTuk61yDgm1c0bdHqIbKFcFx6BlvcpL6Iqkc reEvcw2Thk6O8Mxr8sMYMmgxTwb9Sy0gnFNc0ytipnVDKivN00iCn0jrXLQQAUkE1GUo mrFnxNI+oW8osd4uOOwW0ieayKxYk9ejZY751dtJbq5TK+FZJVD/c+TpQuUIYAPuHBQQ Fx4B+IECc92ftzXnXFCMkdlisjH3E5bMtEnK/TmZVe+8ZBq886uX1PvQQ8RMnERZiNrj Jbrg== X-Gm-Message-State: AOAM530QdHP0uTq4Vh+is5Itr26Bxsh0Jbha3t6x5jAid2q0urR0inuG HFYAqvH7VeT7TBxH+nuVktjirijQj+erlANCPK/AJIzuOLk= X-Google-Smtp-Source: ABdhPJxGe1B8QaowVkr44mqfWoglHuRAOyA9wgv3GKvW8Mben4wLb4UQogc43FAF7B/BorlbYJLN1j1VlRztffyzrS0= X-Received: by 2002:a17:906:8354:: with SMTP id b20mr431277ejy.397.1606745399707; Mon, 30 Nov 2020 06:09:59 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a17:907:217b:0:0:0:0 with HTTP; Mon, 30 Nov 2020 06:09:58 -0800 (PST) In-Reply-To: References: From: hiro <23hiro@gmail.com> Date: Mon, 30 Nov 2020 15:09:58 +0100 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: extended leveraged markup proxy cache Subject: Re: [9front] /dev/draw performance Reply-To: 9front@9front.org Precedence: bulk thanks for doing my basic research anthony, i'm not sure this answers my questions, certainly it adds more questions on my side. :P what i'm curious about is why they changed from blit to draw protocol, especially since a lot of details about draw seem very similar to blit, so i see the historical connection very well, but then what made it necessary to break compatibility on the blit layer and start anew with a similar but incompatible /dev/draw ? and why the /dev/winname vs. /dev/mouse dance in /dev/draw ? when draw in brazil was just plain userland, was it a fileserver? or just library calls like in p9p ? On 11/30/20, Anthony Martin wrote: > 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 >