Re: [9front] /dev/draw performance

[Anthony Martin <ality@pbrane.org>]

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