From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] was 8½ slow and that lead to rio? From: "rob pike" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Message-Id: <20020130161830.46BE619A05@mail.cse.psu.edu> Date: Wed, 30 Jan 2002 11:18:28 -0500 Topicbox-Message-UUID: 494d1108-eaca-11e9-9e20-41e7f4b1d025 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½'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