ADC Home > Reference Library > Technical Q&As > Legacy Documents > Graphics & Imaging >

Legacy Documentclose button

Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.

Current information on this Reference Library topic can be found here:

Native App Slowdown


Q: We are drawing palette icons using a loop which contains the following:

     GetIcon
     HLock
     CopyBits
     ReleaseResource

Our native PowerMacintosh version seems to draw these palettes slower than our 68K version running under emulation, which suggests a Mixed Mode Manager slowdown. All of the routines we call, however, are documented as native on the PowerMac.

Here are some rough but representative timings:

Timings on 8100/80 - 8 bit screen - System 7.5

microseconds percent of loop

GetIcon 2000us 38%

CopyBits 400us 7%

ReleaseResource 2850us 54%

Is it reasonable for CopyBits from a 1-bit bitmap to an 8-bit screen to take less than 10% of the time of this loop? I have verified that all of the icon resources are in memory when this takes place, so the GetIcon & ReleaseResource just need to deal with the resource map.

Aren't all the Resource Manager calls native? These timings seem to indicate they are calling emulated routines.

A: It is not really surprising that you're seeing these numbers, since the Resource Manager calls you are using are not native, and they generally call File Manager routines, which aren't native either. In a way, what you're asking is, which routines are native and which are not? Unfortunately, this is the wrong question: just because something is not native now doesn't mean it never will be. Designing your application based on assumptions you think are valid today is a dangerous thing to do, because your workaround won't necessarily continue to be faster in the future.

Relying on the Resource Manager to be fast is generally not a good idea. Resource files slow down drastically once they reach a certain size (see the Toolbox Technote, "OV 8 Managerial Abuse"). Also, if the resource chain is long, you'll have problems. Since these are icons in a palette, you'll probably want to cache them somewhere, because you'll continually need them as you update your palette.

One approach you can take is to load your icons in one of the first few operations in your initialization code, just after calling MaxApplZone (possibly moving them high and locking them, since you don't want them to move during a CopyBits operation). This technique yields very good performance on the redraws that the palette needs, in exchange for a few kilobytes of memory. Don't forget to mark the resources as non-purgeable, just for good measure.

Rather than using CopyBits, you might want to use the IconUtilities package to obtain and draw your icons (this is documented in Inside Macintosh: More Macintosh Toolbox), either to load an icon family, or to build an icon cache. Using the Icon utilities helps your application to do the right thing for different screen depths. Also, the icon drawing routines are optimized to perform well under a variety of conditions.

Finally, if you need to get at Icons for documents and applications, check out the MoreFiles sample. This is on the Developer CD Series as sample code. DTGetIcon is a useful utility for obtaining Icons.

[May 01 1995]


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.