9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: serge@euler.Berkeley.EDU serge@euler.Berkeley.EDU
Subject: Brazil in Tucson.
Date: Thu,  9 Feb 1995 13:54:55 -0500	[thread overview]
Message-ID: <19950209185455.1dTC2-EmXsCEUN6Qk-nfneY18MoATDtuKQnOmEabLjw@z> (raw)

The abstract in http://www.cs.arizona.edu/people/tics/#pike seems very
interesting, albeit all too brief and tantalizing (would there per any
chance be any more Brazil information available)?  In particular, the
following excerpt raises some intriguing questions:

	For example, the graphics model of the system has been completely
	replaced. Brazil uses a data-based model in which applications
	transmit graphical updates as rectangular blocks of pixels to be
	written directly to the screen or window, rather than the
	traditional description of how to draw the update. This unifies
	traditional user interfaces and video at the lowest levels of the
	system, which, coupled with the model of the file name space
	inherited from Plan 9, makes it possible to display video on the
	display under control of the window system but without the window
	system needing to touch the data: the application can drive the
	display directly.

That is, how does this interact with the current trend for ever more
intelligent graphics controllers, which, e.g. presumably have special
instructions for drawing lines, polygons, etc.?  Also, what does this
due for the communication bandwidth?  I.e., with the ``old'' model,
to draw a line, you would send something like the following packet

	type	= LINE	1 - 8 bytes
	start.x	= XXX	1 - 8 bytes
	start.y	= YYY	1 - 8 bytes
	end.x	= XX2	1 - 8 bytes
	end.y	= YY2	1 - 8 bytes

for a total of (roughly) 5 to 40 bytes.  On the other, hand, with the
new model, the size appears to be unbounded, even for the same line, e.g.


	start.x			= XXX	1 - 8 bytes
	start.y			= YYY	1 - 8 bytes
	end.x			= XX2	1 - 8 bytes
	end.y			= YY2	1 - 8 bytes
	data[Y0][X0].pixel	= RGB	1 - 8 bytes
	data[Y0][X1].pixel	= RGB	1 - 8 bytes
	...
	data[YN][XM].pixel	= RGB	1 - 8 bytes

Does this also mean, that, e.g. a line from (0, 0) to (1024,1024) would
require an entire rectangle of data to be sent?  (Or just individual
dots, which would be nearly as expensive, since you would have to
transmit the coordinates of each?)

Finally, how does one deal with device (e.g. black and white versus gray
scale versus pseudo color versus true color) independence, if the data is
sent directly to the display?  Thank you very much.






             reply	other threads:[~1995-02-09 18:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-02-09 18:54 serge [this message]
  -- strict thread matches above, loose matches on Subject: below --
1995-02-08  5:17 David
1995-02-07 20:39 Jim
1995-01-19 21:56 Jim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19950209185455.1dTC2-EmXsCEUN6Qk-nfneY18MoATDtuKQnOmEabLjw@z \
    --to=serge@euler.berkeley.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).