Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!cogsci!costin From: costin@cogsci.ucsd.EDU (Dan Costin) Newsgroups: comp.sys.mac.programmer Subject: Re: Optimizing Copybits Message-ID: <184@cogsci.ucsd.EDU> Date: 14 Aug 90 04:02:42 GMT References: <1990Aug2.223758.13691@murdoch.acc.Virginia.EDU> <14841@unix.SRI.COM> <9578@goofy.Apple.COM> Reply-To: costin@cogsci (Dan Costin) Distribution: usa Organization: University of California, San Diego Lines: 29 In article <9578@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <14841@unix.SRI.COM> mxmora@unix.UUCP (Matt Mora) writes: >> >>Is that true that a SE/30 can't transfer 22k of data to the screen in >>less than a tick? I find that hard to believe. But then again there > >I find this hard to believe also. 22K is about the size of the original Mac >screen, and a Mac Plus should be able to copy this amount of data in less >than a tick. (If you use 1 CopyBits call and everything is aligned >properly.) > >-- > Larry Rosenstein, Object Specialist Well, I've tried really hard, and couldn't get 22K transferred on a Plus in less than a tick. The fastest I've been able to make it it is in about 18 msec. I would love it if someone could show me how to transfer data to the Mac Plus/SE screen from a buffer faster than 1 tick. What I've had to do, so that the whole screen is displayed in one refresh (also for visual experiment type work), is wait for the screen refresh to start, wait a little longer, and start copying memory over from the top of the screen (or at least in the same direction as the beam draws stuff, which seems to be the opposite of the direction CopyBits copies stuff). That way, when the beam next draws the screen from video RAM, it draws the whole screen. If you don't do this, you might get flickering, since the beam will draw half the old picture and half the new in one pass. -dan