Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ncar!gatech!ncsuvx!news From: kdarling@hobbes.ncsu.edu (Kevin Darling) Newsgroups: comp.arch Subject: Re: Intel graphics chip Keywords: Intel, 586, windows, 82786 Message-ID: <1990Dec21.135409.2069@ncsuvx.ncsu.edu> Date: 21 Dec 90 13:54:09 GMT References: <1990Dec19.115110.15070@ncsuvx.ncsu.edu> <3070@crdos1.crd.ge.COM> <1990Dec19.154145.10137@ux1.cso.uiuc.edu> <1990Dec20.194956.21974@rice.edu> Sender: news@ncsuvx.ncsu.edu (USENET News System) Organization: NCSU Computing Center Lines: 21 Just a note of thanks to those who took the time (and risk ;-) to post their experiences on the 82786 gfx chip. The original reason for bringing it up at all, was the desire someone mentioned of not having to handle window redraws/moves, I believe. I'm in the same situation... I don't mind doing drawing operations myself (in the window manager/driver), but the idea is that applications themselves under this system should not have to worry about redraws (it's a multitasking system, and I've always thought that if the idea was to let each program think it was running alone, then that concept should extend to the virtual terminals on the screen, also :). That pretty much leaves me no choice: covered windows require some backing store, and the drawing routines have to handle (un)covered regions. I've done this before, and never liked the speed results. So having the display hardware combine the separate windows on the visible screen would be great for me. Anyway... Much thanks again! As I mentioned, I'd not seen the chip beyond one or two articles yet. Always good to hear opinions first. cheers - kevin