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.
next 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).