mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) (08/03/90)
We need to optimize the speed with which copybits places a complex image from an offscreen port to the screen. We are working with an SE (2.5Mb RAM), to which we have attached a 19" monitor (LaserView by Sigma Designs). We can't seem to get any image to be copied in under 50-60 msec (which is about 3-4 refresh scans). Each image to be transferred is under 20K in size. We are using SrcCopy. we have defined the source rectangle in the offscreen port to be the size of the monitor's screen size. We have defined the destination rectangle to be the same size as the entire screen. However, we define the clipping region to be the size the PICT's picture frame (which is centered on both ports' portrect). (We have also tried making the destination rectangle and the source rectangle the same size as the PICT's picframe, and then clipping the drawing region on the screen to the size of the picframe also. This doesn't make the copy procedure more efficient, since in both cases the clipping region is the same size as the PICT's picframe.) Because we are using a large-screen monitor, we cannot use an accelerator board (at least, given the monitor we are using, since no company manufactures an accelerator with an adaptor for our monitor). We happened to expand RAM from 1 Meg to 2.5 Meg and surprisingly to us, we cut down the drawing time to 1/4 of what it was before the upgrade. If we expanded to 4 meg, would we cut down on the drawing time further? (Why did additional RAM speed up the copybits procedure in the first place?) What more can we do? What are we doing wrong? We need to get the drawing times as close to 1 refresh cycle as possible. (This program is for an experiment in visual perception.) Any help would be greatly appreciated. -------------------------------------------------------------------------- Maria Lasaga Department of Psychology Gilmer Hall University of Virginia Charlottesville, Virginia 22903 e-mail: MIL@virginia.bitnet --------------------------------------------------------------------------
jackiw@cs.swarthmore.edu (Nick Jackiw) (08/03/90)
mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: > > > We need to optimize the speed with which copybits places a complex > image from an offscreen port to the screen. > Based on your description, there are a couple more tweaks you can try. Make sure that the bit-maps are bit-aligned; i. e. that one pixel occupies the same bit (in whichever word its located in) in both the source and destination bitmaps. This keeps Quickdraw from having to rotate the data's bits before storing them. Also, make sure that rowBytes, and your srcRect/destRect's width, are multiples of four--this lets the processor copy data at maximum speed. In TechNote#277, Forrest Tanaka describes a number of the more significant factors which determine the speed of copyBits. Additionally, I'll send you (by e-mail) a more thorough description of bit alignment. > > We happened to expand RAM from 1 Meg to 2.5 Meg and surprisingly > to us, we cut down the drawing time to 1/4 of what it was before > the upgrade. If we expanded to 4 meg, would we cut down on the > drawing time further? (Why did additional RAM speed up the > copybits procedure in the first place?) No idea whatsoever. Even if the new RAM were faster, that shouldn't influence the actual access speed. If you're unloading and reloading segments from disk, a larger memory partition will of course reduce this activity. But if you're trying to optimize copyBits, cutting out disk activity altogether is the best place to start... > > What more can we do? What are we doing wrong? We need to get > the drawing times as close to 1 refresh cycle as possible. (This > program is for an experiment in visual perception.) 20K of data at 60hz? I doubt you'll make it. My SE/30 can't do that in a tight display loop with major optimizations in place... > -------------------------------------------------------------------------- > Maria Lasaga > Department of Psychology > Gilmer Hall > University of Virginia > Charlottesville, Virginia 22903 > -------------------------------------------------------------------------- -- ------------------------ Nick Jackiw jackiw@cs.swarthmore.edu "Every minute of the future Visual Geometry Project jackiw@swarthmr.bitnet is a memory of the past." Swarthmore College, PA 19081-1397 -Laivach
mxmora@unix.SRI.COM (Matt Mora) (08/03/90)
In article <KPHN70@cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes: >mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: >> What more can we do? What are we doing wrong? We need to get >> the drawing times as close to 1 refresh cycle as possible. (This >> program is for an experiment in visual perception.) > >20K of data at 60hz? I doubt you'll make it. My SE/30 can't do that in a >tight display loop with major optimizations in place... 20K ? He's trying to do it for a 19" monitor. My 13" monitor is 640 x 480 = 300K. I'm not sure what the pixel dimensions are for a 19" monitor but I seriously doubt that it can be done. There probably wasn't enough memory to transfer all that data to the video card with only 1 meg so copybits had to do it in bands. 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 is probably so much overhead in the system these days that we are going to need a 68040 just to boot :-) >------------------------ >Nick Jackiw jackiw@cs.swarthmore.edu "Every minute of the future -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________
lsr@Apple.COM (Larry Rosenstein) (08/04/90)
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 Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
larsen@ginger.princeton.edu (Michael Larsen) (08/08/90)
In article <KPHN70@cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes: >mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: ] ] We need to optimize the speed with which copybits places a complex ] image from an offscreen port to the screen. ] >20K of data at 60hz? I doubt you'll make it. My SE/30 can't do that in a >tight display loop with major optimizations in place... I don't know about CopyBits performance, but you should certainly be able to load video RAM faster than that by hand. On my Mac II, it takes ~12 msec to fill the screen in 1-bit mode (38K) from a buffer in memory. So even an SE ought to be able to copy 20K to video memory in no more than 2 screen refreshes. -Michael Larsen
jwhitnell@cup.portal.com (Jerry D Whitnell) (08/10/90)
In article <KPHN70@cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) wr ites: >mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: ] ] We need to optimize the speed with which copybits places a complex ] image from an offscreen port to the screen. ] There is a recent Apple tech note dealing with just this subject. My notes are at work, so I can't give you the number but check for more info on how to optimize copybits. Jerry Whitnell SuperMac Technology
costin@cogsci.ucsd.EDU (Dan Costin) (08/14/90)
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