[comp.sys.mac.programmer] Mac IIfx twice as slow as Mac II !!!!!

jenlan@eos (Jennifer S Lanham) (12/06/90)

Hello,
I have an unusual occurance: During a certain procedure, the
Mac IIfx is twice as slow when compared
to other Mac II family members ( Mac IIci, Mac II, Mac IIx).
Needless to say, I am surprised. This slowness was observed in special
circumstance described below. If anyone has clues as to what I have done
wrong...let me know! Thank YOU! And now the rest of the story......



  I timed this on the Mac's listed above and the fx is twice as slow!!
  (I tried two fx's and both were slow!)

  So is the graphics device code obsolete, or is there twice as many
  vertical synch waits, or does it have to do with addressing?????

/*The code segment draws a circle using a specified entry (#2) of the graphics
device color table. The RGBForeColor parameter assures that entry # 2 is
used. A graphics device control call, is used to blast new values
into entry #2. A fast and dirty draw. For most drivers, built into this control
call is that it waits for vertical blanking to be true before changing
the video CLUT. NOTE: the code for GDSetEntries is copyright 1989, 1990
by Dennis Pelli and is part of VideoToolbox, a library of low level routines
for controlling graphics devices*/

GDHandle theDev;
ColorSpec  theCols[2];
int tempCt, error;
Rect aRect;
.
./*in here theCols are filled with R,G,B values*/
.
theDev = GetMainDevice(); /*getting the device to access the CLUT*/
SetRect(&aRect,100,100,150,150);
/*painting the oval with specified device entry's rgb*/
RGBForeColor(&(**(**(**theDev).gdPMap).pmTable).ctTable[2].rgb);
PaintOval(&aRect);

for(tempCt = 0;tempCt < 3000;tempCt++)
{/*see below for param types..note 0 in the call is zero based meaning one
   entry*/
	error = GDSetEntries(theDev, (short) 2, (short) 0, &theCols[0]);
	error = GDSetEntries(theDev, (short)2, (short) 0, &theCols[1]);
}

	
/*This code copyright Dennis Pelli 1989, 1990*/
OSErr GDSetEntries(myGDHandle,start,count,aTable)
GDHandle myGDHandle;
short start;
short count;
ColorSpec *aTable;
/*
The arguments start, count, and aTable are the same as for the Color Manager 
call SetEntries(), documented in Inside Macintosh V-143. 
*/
{
	VDSetEntryRecord myVDSetEntryRecord;
	OSErr error;

	if(myGDHandle==NULL) return controlErr;
	myVDSetEntryRecord.csStart=start;
	myVDSetEntryRecord.csCount=count;
	myVDSetEntryRecord.csTable=aTable;
	error=GDControl((*myGDHandle)->gdRefNum,setEntries,(Ptr) &myVDSetEntryRecord);
	return error;
}


Thanks again, if you have read this far.....

Jennifer
jenlan@eos.arc.nasa.gov

mrn@eplunix.UUCP (Mark R. Nilsen) (12/08/90)

in article <7663@eos.arc.nasa.gov>, jenlan@eos (Jennifer S Lanham) says:
> 
> Hello,
> I have an unusual occurance: During a certain procedure, the
> Mac IIfx is twice as slow when compared
> to other Mac II family members ( Mac IIci, Mac II, Mac IIx).

On the cover of PCWEAK [sic] December 3, 1990 Vol. 7 No. 48. an
article reads:

	ROM BUG HINDERS MEMORY MANAGER IN 4 MAC MODLES

	Apple Computer Inc. is working to address a bug in the
	ROM of several Macintosh models (ci si LC fx) that can
	radically slow performance of some highly complex
	applications, ...

	The problem is said to involve the Memory Manager, and all
	Mac programmers know how complicated a Macintosh program has
	to be to call the Memory Manager (cough).  It went on to give
	specifics but no solution yet.  It affects 270,000 machines so
	far.  

	Good luck with this.  The press has the scoop but I'll be
	interested in seeing a mass-mailing from Apple.

	--Mark. 
	eplunix!mrn@eddie.mit.edu