Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!zooey.Berkeley.EDU!c162-fe
From: c162-fe@zooey.Berkeley.EDU (Jonathan Dubman)
Newsgroups: comp.sys.amiga
Subject: Instant Windows (making the copper/blitter obsolete)
Message-ID: <2007@pasteur.Berkeley.Edu>
Date: 2 Apr 88 03:20:44 GMT
Sender: news@pasteur.Berkeley.Edu
Reply-To: c162-fe@zooey.Berkeley.EDU (Jonathan Dubman)
Organization: University of California, Berkeley
Lines: 68

A little while back (in the Mac II vs. Amiga article) I mentioned that I had
an idea that would make the blitter obsolete.  Well, here it is.

* How would you like to drag windows as smoothly as you drag screens, not just
  dragging the outline, but dragging the whole window and its contents?

* How would you like arbitrarily fast animation of large regions?

The principle is so simple that I am sure it has been thought of before:
EVERY WINDOW IS A HUGE SPRITE.  The graphics chip can handle multiple
overlapping rectangular regions with differing priorities and (maybe) palette.
In essence, it is more like the copper than the blitter.  To move a window,
merely change the x and y positions.  The chip could handle off-screen movement
and clipping very easily.  To move a window to the front, merely shuffle the
priorities.  No refreshing.  No software clipping.  Can you say,
"blindingly fast"?

This ain't no pipe dream.  I have a decent idea of how to design it, and I'm not
even a "hardware person".  The problem with the copper is that it is trying to
reload the palette and so forth WHILE it is extremely busy sending bits to the
video generation circuitry.  It takes one blank line to change resolutions and
so forth.  A better solution is to separate the functions (like two small
parallel processors in a master-slave relationship.)  One part, the "bottom"
part, looks in memory and sends bits to the video generation circuitry (which
handles horizontal and vertical sync, A-D conversion, etc.)  The "top" part,
every once in a while, resets the counter to point to a different bitmap
in memory.  Jay Miner et al did the gruntwork during the horizontal retrace,
when the copper wouldn't be busy spewing out bits.  Well, while not use
very simple parallel processing and get around the whole problem?  The whole
thing is not difficult even in concept, much less in execution.  Low
memory bandwidth, incredible performance by today's standards.  And the
windowing idea is not going away.  You get higher bandwidth if you worry
about transparency, which i would insist upon, but parallel processing can
lower the bandwidth with very little overhead.  And each of the processors
is extremely simple- I'm talking equivalent of a dozen counters and latches,
etc.  Naturally, there will have to be some finite limit to the "see-through",
like 8 deep or something.

THE KEY IDEA
The key is to distinguish that which must change memory from that which
need not.  A graphics coprocessor that does 3d wire frame drawing needs to
change memory.  A windowing chip doesn't NEED to change some big bitmap in
memory.  Think of the overhead- we spend a lot of time moving bits into a huge
bitmap (the screen bitmap) which later we spend a lot of time moving bits out
of!  Why the silly intermediary step?

Have you ever used a Mac II?  The window motion is SOOOOO SLOW.  It is very
annoying to use.  The slowness of the graphics and the inability to distinguish
conceptual contexts (can't have different programs on different screens- you
just get everything running on one cluttered screen that each application
probably completely fills) are the major reasons preventing me from getting
one.  (Oh, and also the price.)

Actually, this whole idea started when I was using a Mac II and thinking about
how much software complication there is just in moving the mouse pointer
around on the screen.  The mouse pointer flickered wildly as it was
constantly overwritten and updated.  Then I thought of sprites and how handy
they were, but they were a departure from the elegant (but slow) standard
bitmapped screen.  And then a friend of mine, Ofer Licht, made the critical
step:  why not link sprites together, across the screen, to make a huge
sprite, and use that for moving small windows?  Well, why stop at small
windows?

OK- I'm ready for the bad news.  Somebody respond and tell me that Fairchild
or Texas Instruments or somebody has had the GFX1152 for three years that
already does everythig I'm saying.

cu,
	*&(Jonathan Dubman)