Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (Under Construction) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: How do you draw to the screen quickly? Message-ID: Date: 9 Feb 90 19:01:05 GMT References: <21908@pasteur.Berkeley.EDU> Sender: news@decwrl.dec.com Organization: Missionaria Phonibalonica Lines: 36 In-reply-to: jwz@teak.berkeley.edu's message of 8 Feb 90 22:43:11 GMT >> I just recently got "popi", the image processing program described in >> Gerald Holzmann's book "The Digital Darkroom"; this program runs on a variety >> of systems, but the conditionally-compiled Amiga code is really really slow, >> and I'd like to fix this. So. The problem isn't really the Amiga specific code; the problem is that the thing is just plain slow (it's barely useable on a DECStation 3100, at 14 MIPS). The heart of the code is a loop that interprets the stack-machine code for the transformation expression once for every pixel on the screen. The easy solution is to use fewer pixels - say 128x128 instead of 512x512; giving you a factor of 16 increase in speed with no work. The hard solution is to rewrite the "compiler" to generate a loop that runs in 68K machine language & run that, instead of generating stack-machine code and interpreting that (this is what pico, mentioned in the book, did). An intermediate solution is to write something that translates the stack-machine code into 68K ML, and run that instead of the stack-machine code. Of course, speeding up the display code wouldn't hurt. But I don't see much point until the transformation code is fixed. In any case, the best way I can see to do the drawing code is to have the blitter move one (two?) bit-plane at a time from the image array into the drawing area. You could also do this for each scan line, but that will be slower. Whatever you do, let us know!