Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!phil
From: phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN)
Newsgroups: comp.windows.ms
Subject: Re: slowness of screen drivers
Message-ID: <1991Jun10.200019.24609@ux1.cso.uiuc.edu>
Date: 10 Jun 91 20:00:19 GMT
References: <1991Jun7.100103.8975@Informatik.TU-Muenchen.DE>
Organization: University of Illinois at Urbana
Lines: 26

How about a video board that has VRAM and a video scanning scheme that can
alter the real time video scanning address sequence so that each window can
be placed in whole in its own memory location (provided you have enough VRAM
to hold all the windows in full) despite where it is displayed on the screen
(which is simply WHEN it is scanned out).

Coprocessors can still be used to do fast bit-blt type operations on the
window contents, but with the advantage that it does not have to deal with
the hidden portions of the window, and the windowing system would not have
to also apply these operations to, or cancel, any backing store that might
be used (e.g. X servers) since there would be no backing store.

Each window can have its own private pallette and can even operate in its
own modes.  One window might be 32 bits per pixel while another is simply
2 bits per pixel.

Imagine dragging a window smoothly across the screen while the image of the
earth shown in it is rotating at the same time, with not even the slightest
pause out of the system.  The window position numbers would be updated while
the coprocessor is rotating the earth image.  The window shape can even be
round.
-- 
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/