Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!van-bc!rsoft!mindlink!a464
From: a464@mindlink.UUCP (Bruce Dawson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: How do you draw to the screen quickly?
Message-ID: <1092@mindlink.UUCP>
Date: 9 Feb 90 14:41:30 GMT
Organization: MIND LINK! - British Columbia, Canada
Lines: 25


     One way of speeding this up is to write your own WritePixel() routine.
This ONLY works if you have opened a custom screen and you aren't going to be
having any windows over top of the window you are writing in to.  You also have
to make sure that menus don't come down over top while you are writing pixels,
or your results will have holes in them.  You can use LockLayers() or some such
to prevent that from happening, but you'd better not LockLayers() for every
pixel or performance will still be really poor (ie; do a LockLayers(), render a
bunch of pixels, then do an UnLockLayers() would work).

     Another way, probably better, is to create a one scan-line buffer. Use
some assembler code to translate an array of colours into your buffer, then use
DrawImage() or some such to render the whole line onto the screen/window.  This
is more robust.  Warning:  When I last checked (several years ago I admit),
DrawImage didn't block menus (ie; didn't do a LockLayers()), meaning that menus
could drop down and get drawn over by DrawImage(), thus munging the display.
If this is still true, put your own LockLayers() calls around calls to
DrawImage.

     All of this is irrelevant if the calcs are the real CPU hog.  Write a
program to just write pixels to the screen and time it.  If it takes 1% as long
as the program your optimizing, ignore screen write time.  If it takes 50% as
long...

.Bruce.