From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 30 Nov 1995 11:03:53 -0500
From: Al Varney varney@ihgp5.ih.att.com
Subject: Graphics issues
Topicbox-Message-UUID: 36e69004-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19951130160353.8qCWQoQAO1IMu1NKispgZDMSe01cjn7pxy_2VE0QvK4@z>

In article <9511171105.AA16712@idnewt.idsoftware.com>,
John Carmack <9fans@cse.psu.edu> wrote:

>All of my event issues would be resolved with two changes to the =
>current interface:
>
>The mouse device must buffer state transitions, so clicks are =
>never missed.  This could be done transparently to current code.
>
>A raw keyboard device would need to be created that includes key =
>ups if available and time stamps the actions so they can be =
>accurately interleaved with mouse events.

   If you can find some old documentation on the Commodore Amiga,
take a look at its "food chain" that passes keyboard (raw up/down)
and mouse events via messages to an ordered list of processes that
ask for them -- with time stamps.  Looks a lot like the Mac mechanism,
but more "process" oriented.  If the chain is ordered by timestamp,
you have a reasonably integrated mouse/keyboard input mechanism.
And all this could be treated as a raw device (/dev/"raw food")?



>I think that plan9 would be an excellent environment to write a =
>video rate aware graphics/window system.
>
>Digression: In some extreme programming forms (demo coding), =
>drawing is sometimes performed in a controled enough fashion that =
>it can be direct to screen and manage to never produce an =
>inconsistant image by being totally aware of the relationship =
>between the location of the drawing and the current position of =
>the raster, but that isn't generaly useful.
>
>....  If PCs had scan line interrupts, that would even be a =
>practical thing to do...

   Amiga....  While per-scan-line changes in color translation tables
and display content might be OK for demos, it probably isn't useful when
multiple processes are each changing parts of the display simultaneously.
Unless you could have hardware hide the effects.  Maybe buffer vram
writes that are "ahead" of the raster in a "shadow" vram, then write-through
any changed areas after the raster passes ---- ughh, nope, forget it...

>The answer is to keep the window bitmaps in offscreen vram and =
>have the accelerator do the pixel pushing.

   Seriously, why not have the vram be part of the host ram memory space???
(Just don't cache that area.)

>Digression 2:  the next generation of PCI video cards are going to =
>support bus mastering, with the ability to pull pixels directly =
>out of host memory at speeds of up to nearly 100 megs a second.  I =
>doubt the main memory systems will be able to feed them that fast, =
>though.  It will change a lot of design decisions.

   Again, the Amiga model (sort of) has video take pixels from host
memory (and a DMA-based hardware Blitter that can synchronize with
raster position).  You might want to look at this "old" windowing
mechanism that supports a hierarchy of independent Screens
with Windows, although the windowing part seems to borrow a lot from the
Xerox/Mac model.

   Maybe the ultimate answer is non-raster displays.  But how would you "hide"
update details from a screen that instantly shows every pixel change!!

Al Varney