* [9front] /dev/draw performance @ 2020-11-30 8:03 Steve Simon 2020-11-30 9:34 ` hiro 2020-11-30 18:40 ` Ethan Gardener 0 siblings, 2 replies; 7+ messages in thread From: Steve Simon @ 2020-11-30 8:03 UTC (permalink / raw) To: 9front quote: “The current windowing/graphics setup with /dev/draw as a kernel device and rio itself was implemented after Thompson, Ritchie, and Pike left Bell Labs and others thought the window system needed optimizing.” This is not my memory. work on plan9 switched to Brazil in 95, i believe it was seen as an experimental branch to try some major changes. the switch from 81/2 to rio and the new /dev/draw model was a major part of this. This was back ported to plan9 in time for the 3rd release in 2000 - just around the time many left the labs. I am not saying rio cannot be improved, but characterising it as inferior work by inferior people is (i feel) unfair and incorrect. -Steve ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] /dev/draw performance 2020-11-30 8:03 [9front] /dev/draw performance Steve Simon @ 2020-11-30 9:34 ` hiro 2020-11-30 12:22 ` Anthony Martin 2020-11-30 18:40 ` Ethan Gardener 1 sibling, 1 reply; 7+ messages in thread From: hiro @ 2020-11-30 9:34 UTC (permalink / raw) To: 9front nobody said anything about people being inferior. obviously when the next generation of people stampedes into the unix room they might do thinks differently. they might have different goals and different visions. the can be less consistent than before. the more people that are involved the less coherence. so there are enough non-personal reasons that explain it. 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. On 11/30/20, Steve Simon <steve@quintile.net> wrote: > > quote: “The current windowing/graphics setup with /dev/draw as a kernel > device and rio itself was implemented after Thompson, Ritchie, and Pike left > Bell Labs and others thought the window system needed optimizing.” > > This is not my memory. > > work on plan9 switched to Brazil in 95, i believe it was seen as an > experimental branch to try some major changes. the switch from 81/2 to rio > and the new /dev/draw model was a major part of this. This was back ported > to plan9 in time for the 3rd release in 2000 - just around the time many > left the labs. > > I am not saying rio cannot be improved, but characterising it as inferior > work by inferior people is (i feel) unfair and incorrect. > > -Steve > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] /dev/draw performance 2020-11-30 9:34 ` hiro @ 2020-11-30 12:22 ` Anthony Martin 2020-11-30 14:09 ` hiro 0 siblings, 1 reply; 7+ messages in thread From: Anthony Martin @ 2020-11-30 12:22 UTC (permalink / raw) To: 9front 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½ slow and that lead to rio? From: "rob pike" <rob@plan9.bell-labs.com> 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½'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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] /dev/draw performance 2020-11-30 12:22 ` Anthony Martin @ 2020-11-30 14:09 ` hiro 0 siblings, 0 replies; 7+ messages in thread From: hiro @ 2020-11-30 14:09 UTC (permalink / raw) To: 9front 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 <ality@pbrane.org> 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½ slow and that lead to rio? > From: "rob pike" <rob@plan9.bell-labs.com> > 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½'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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] /dev/draw performance 2020-11-30 8:03 [9front] /dev/draw performance Steve Simon 2020-11-30 9:34 ` hiro @ 2020-11-30 18:40 ` Ethan Gardener 2020-11-30 18:59 ` Stanley Lieber 1 sibling, 1 reply; 7+ messages in thread From: Ethan Gardener @ 2020-11-30 18:40 UTC (permalink / raw) To: 9front On Mon, Nov 30, 2020, at 8:03 AM, Steve Simon wrote: > > I am not saying rio cannot be improved, but characterising it as > inferior work by inferior people is (i feel) unfair and incorrect. I realise my statements could be read that way. I intended to mean people with different goals, but regardless, I'm sorry to those involved. Anthony is also correct. It's a bad habit I got into a long time ago and can't seem to quit, especially where Plan 9 is involved. I entirely missed learning about Brazil when Stanley Lieber and others were no doubt researching it. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] /dev/draw performance 2020-11-30 18:40 ` Ethan Gardener @ 2020-11-30 18:59 ` Stanley Lieber 2020-11-30 19:01 ` Ethan Gardener 0 siblings, 1 reply; 7+ messages in thread From: Stanley Lieber @ 2020-11-30 18:59 UTC (permalink / raw) To: 9front On November 30, 2020 1:40:32 PM EST, Ethan Gardener <eekee57@fastmail.fm> wrote: >On Mon, Nov 30, 2020, at 8:03 AM, Steve Simon wrote: >> >> I am not saying rio cannot be improved, but characterising it as >> inferior work by inferior people is (i feel) unfair and incorrect. > >I realise my statements could be read that way. I intended to mean people with different goals, but regardless, I'm sorry to those involved. > >Anthony is also correct. It's a bad habit I got into a long time ago and can't seem to quit, especially where Plan 9 is involved. I entirely missed learning about Brazil when Stanley Lieber and others were no doubt researching it. to be fair, public information about unreleased projects at the labs is both sparse and confusing. sl ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] /dev/draw performance 2020-11-30 18:59 ` Stanley Lieber @ 2020-11-30 19:01 ` Ethan Gardener 0 siblings, 0 replies; 7+ messages in thread From: Ethan Gardener @ 2020-11-30 19:01 UTC (permalink / raw) To: 9front On Mon, Nov 30, 2020, at 6:59 PM, Stanley Lieber wrote: > On November 30, 2020 1:40:32 PM EST, Ethan Gardener <eekee57@fastmail.fm> wrote: > >On Mon, Nov 30, 2020, at 8:03 AM, Steve Simon wrote: > >> > >> I am not saying rio cannot be improved, but characterising it as > >> inferior work by inferior people is (i feel) unfair and incorrect. > > > >I realise my statements could be read that way. I intended to mean people with different goals, but regardless, I'm sorry to those involved. > > > >Anthony is also correct. It's a bad habit I got into a long time ago and can't seem to quit, especially where Plan 9 is involved. I entirely missed learning about Brazil when Stanley Lieber and others were no doubt researching it. > > to be fair, public information about unreleased projects at the labs is > both sparse and confusing. Thanks. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-11-30 19:23 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-30 8:03 [9front] /dev/draw performance Steve Simon 2020-11-30 9:34 ` hiro 2020-11-30 12:22 ` Anthony Martin 2020-11-30 14:09 ` hiro 2020-11-30 18:40 ` Ethan Gardener 2020-11-30 18:59 ` Stanley Lieber 2020-11-30 19:01 ` Ethan Gardener
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).