Re: [9front] /dev/draw performance

[hiro <23hiro@gmail.com>]

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
>