[9front] /dev/draw performance

[9front] /dev/draw performance

[Steve Simon]

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

Re: [9front] /dev/draw performance

[hiro]

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
>
>

Re: [9front] /dev/draw performance

[Anthony Martin]

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

Re: [9front] /dev/draw performance

[hiro]

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
>

Re: [9front] /dev/draw performance

[Ethan Gardener]

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.

Re: [9front] /dev/draw performance

[Stanley Lieber]

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

Re: [9front] /dev/draw performance

[Ethan Gardener]

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.