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