Path: utzoo!utgpu!cunews!cognos!geovision!gd From: gd@geovision.gvc.com (Gord Deinstadt) Newsgroups: comp.arch Subject: Re: Dynamic Display Architecture Message-ID: <1504@geovision.gvc.com> Date: 18 Apr 91 16:04:56 GMT References: <1991Apr15.200955.3438@waikato.ac.nz> <3340@crdos1.crd.ge.COM> <20670@cbmvax.commodore.com> <1991Apr17.051746.15592@sbcs.sunysb.edu> Organization: GeoVision Corp., Ottawa, Ontario Lines: 26 zik@dec19.cs.monash.edu.au (Michael Saleeba) writes: [Block-based windowing] >One device which did exactly this was the Texas Instruments TMS9929A (and >others in the same family). [...] >It also had hardware sprites and some other goodies. Quite a nice system >in a limited sort of way, and it certainly made eight-pixel scrolling quick >as you point out. Unfortunately standard bit-scrolling was slower than ever >since you had to keep track of all those pointers (actually character- >generator blocks). The idea (well, as I saw it) is to NOT DO standard bit-scrolling - force windows to fall on boundaries that are convenient to the hardware. This makes more sense on cheap H/W than trying to be totally general and taking forever to do anything (ie. trying to deliver everything and delivering nothing). Of course an application may still have to bit-scroll part of an image within a window, but this is the application's problem; it is slower, but the slowness "feels" better because the computer is actually "doing" something at the time. It was only marginally slower anyway - as I had it set up, each window was a regular rectangular array in memory. The additional processing was caused by the awkward ordering of pixels within each block or tile. The pointers were only used by the windowing system as a fast index for repainting. Essentially, that's all this is - an inverted index for display memory. -- Gord Deinstadt gdeinstadt@geovision.UUCP