Re: [9fans] Why rio instead of 8 1/2

[okamoto@granite.cias.osakafu-u.ac.jp]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Thank you very much Rob.

It's not easy to understand Rio to me, because this is my first 
experience to see her functions and implementation.  Please
forgive me if I'm too noisy on this topic.

When I do "ps", I find 7 rio processes for one window.  I now
think I got it right(???).  Those are, in the order from early to late,
1) main process, 
2) mouseproc made from initmouse(), 
3) kbdproc from initkeyboard(), 
4) timeproc from timeinit(), 
5) wctlproc from filsysinit() in fsys.c, 
6) filsysproc also from the same function as (5), 
7) /bin/rc or approapriate file to be called
        called from initcmd() or new().

Then, No. (2) and (5) procs are marked as rendez.  I looked into
sources, however, I failed to understand where the No.2 and 5
processes are called rendezvous.  I know I'm missing something...

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 3054 bytes --]

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: [9fans] Why rio instead of 8 1/2
Date: Sat, 8 Jul 2000 15:15:10 -0400
Message-ID: <200007081915.PAA03839@cse.psu.edu>

> Please make me clear what is the reason why the new release adopted new 
> graphic model.

Many reasons.  Most important is that the bitblt model is twenty years
old now and woefully inadequate for representing the kinds of things
people do in modern interfaces on modern machines.  The old stuff
didn't even have the *idea* of color, let alone a way to use it.  And
for multibit colored pixels, operations like AND and OR are usually
nonsense.  XOR still has merit, but losing XOR was a small price to
pay for the greater generality of alpha-blended image composition.

Another reason is that we needed to move to true color, which is not a
power of two bits per pixel, and is multichannel, which further
reduces the suitability of bitblt.

Another reason is that compiling on the fly, although a great idea in
1981 and perhaps in the future, is problematic for a portable system.
If all we had was x86s we might be able to make it work, but with
MIPS, SPARC, ARM, PowerPC, Alpha - and the list continues to grow -
the difficulty of maintaining multiple on-the-fly compilers pales
beside the problem of keeping caches synchronized when the
architectures often leave caching details up to the motherboard
builder.  The last release of Plan 9 represented the limits of our
ability to cope.  On-the-fly compilation for bitblt had to go.

Another reason is that we wanted to use VGA accelerator hardware.

Finally, it was time for a change in the way the system worked.  It
just looked old.

So we redid it all. That's the way we work.

The X people are wrestling with many of these issues today.

-rob