Path: utzoo!utgpu!jarvis.csri.toronto.edu!utcsri!me!radio!cks
From: cks@radio.toronto.edu (Chris Siebenmann)
Newsgroups: comp.sys.amiga
Subject: Re: BltBitMap() problems.
Message-ID: <961@radio.toronto.edu>
Date: 22 Feb 88 05:27:52 GMT
Article-I.D.: radio.961
Posted: Mon Feb 22 00:27:52 1988
References: <1081@percival.UUCP>
Reply-To: cks@radio.UUCP (Chris Siebenmann)
Organization: Newsaholics Anonymous
Lines: 22
Keywords: Help!
Summary: 1.2 BltBitMap bug


 While this isn't your problem, everyone should be aware of a
BltBitMap() bug I stumbled across a while back. One of BltBitMap()'s
parameters is a temporary memory buffer for overlapping copies (tempA,
the last parameter). In 1.1, you had to allocate this yourself; in 1.2
the OS is supposed to do this for you.

 Well, it does. Of course, they never promised it would deallocate it
afterwards, and it doesn't. If you have lots of overlapping
BltBitMap()s, this can really eat chip memory quite fast, and in any
case it's eating precious chip memory. The easiest way of seeing this
bug in action is to write a program that does overlapping BltBitMap()s
in a loop (I threw out my example program, unfortunately) and watch
the chip memory total. Be sure to stick a delay in between each call,
or you won't be able to see the memory go down; the machine will just
crash.

-- 
	"I shall clasp my hands together and bow to the corners of the world."
			Number Ten Ox, "Bridge of Birds"
Chris Siebenmann		{allegra,mnetor,decvax,pyramid}!utgpu!radio!cks
cks@radio.toronto.edu	     or	...!utgpu!{chp!hak!ziebmef,ontmoh}!cks