Oct 94 Tips
Volume Number: | | 10
|
Issue Number: | | 10
|
Column Tag: | | Tips &Tidbits
|
Related Info: Color Quickdraw
Tips &Tidbits ![](img001.gif)
By Scott T Boyd, Editor
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
![](img003.gif)
Tip Of The Month
Faster Color
RGBForeColor and RGBBackColor can take a surprising amount of time, especially if your main drawing loop calls both routines before most drawing operations. Even if you call RGBForeColor with the color thats currently foremost, it still recalculates the best possible foreground color! By remembering the results of RGBForeColor and RGBBackColor, you can significantly increase your drawing speed; this example program shows a drawing speed increase of 20%!
The program is written to be pasted into a brand new Think C Project; no MacTraps library is required here. It dumps you into MacsBug at the end with location $40 holding the unoptimized time and $44 holding the optimized time. You can use locations $40 through $5B, inclusive, for debugging purposes.
/* 1 */
#include <QuickDraw.h>
#include <Windows.h>
#include <Palettes.h>
#include <Events.h>
void main(void) {
CWindowRecord cwr;
WindowPtr wp;
Rect bounds = {100, 50, 100 + 256, 50 + 100};
RGBColor theColor;
unsigned short i, lp;
unsigned short start, stop, inc;
long startT, stopT;
long ColorIndex[1000];
short optimized;
InitGraf( NewPtr(2000) + 1000);
InitCursor();
InitFonts();
InitWindows();
InitMenus();
TEInit();
InitDialogs(0);
wp = NewCWindow(&cwr,&bounds,"\pFill",TRUE,zoomDocProc,0,TRUE,237);
SetPort(wp);
OffsetRect(&bounds, -bounds.left, -bounds.top);
for (optimized = 0; optimized <= 1; optimized++) {
startT = TickCount();
if (optimized) {
for (i = 0; i < 256 * 255; i += 256) {
theColor.red = i;
theColor.green = i;
theColor.blue = i;
RGBForeColor(&theColor);
ColorIndex[i >> 8] = cwr.port.fgColor;
}
}
PenPat((Pattern *)"\xF0\xF0\xF0\xF0\xF0\xF0\xF0\xF0");
for (lp = 0; lp < 99; lp++) {
MoveTo(0, 0);
if (lp & 1) {
start = 0;
inc = 256;
stop = 256 * 255;
} else {
stop = 0;
start = 256 * 255;
inc = -256;
}
for (i = start; i != stop; i += inc) {
if (!optimized) {
theColor.red = theColor.green
= theColor.blue
= i;
RGBForeColor(&theColor);
theColor.red = theColor.green
= theColor.blue
= 65536 - 256 - i;
RGBBackColor(&theColor);
} else {
cwr.port.rgbFgColor.red
= cwr.port.rgbFgColor.green
= cwr.port.rgbFgColor.blue
= i;
cwr.port.fgColor =
ColorIndex[cwr.port.rgbFgColor.red >> 8];
cwr.port.rgbBkColor.red
= cwr.port.rgbBkColor.green
= cwr.port.rgbBkColor.blue
= 65536 - 256 - i;
cwr.port.bkColor =
ColorIndex[cwr.port.rgbBkColor.red >> 8];
}
Line(100, 0);
Move(-100, 1);
}
}
stopT = TickCount();
if (!optimized) {
*(long *)0x40 = stopT - startT;
} else {
*(long *)0x44 = stopT - startT;
}
}
DebugStr("\p;dm 40");
CloseWindow(wp);
}
- Jörg jbx Brown
San Francisco, CA
Got a developer tip youve been keeping to yourself but really need to share? Think you have a better trick up your sleeve? Send us your tips and tricks, especially programming-related tips, but dont hold back if youve got programmers user tips.
We want your tips! We pay $25 for every tip used, and $50 for Tip of the Month. You can take your award in orders or subscriptions if you prefer.
Make sure code compiles, and send tips by e-mail. See page two for our addresses.
Not Such A Drag After All
The drag manager is really cool and can make apps a lot more intuitive, but its a pain to debug since process switches are disabled while drags occur. Since both Think Cs and Metrowerks debugger require these, you cannot use them. Never fear! You can use The Debugger!
While were on the subject, heres a gotcha for you. Watch out for a bug that causes deadlock if you call WaitNextevent from a drag receive handler.
- Rod Magnuson,
Cupertino, CA
Going Faster with Symantec TPM
Symantec C++, both versions 6.0 and 7.0, do not have the compilers as part of Think Project Manager. Instead, they are kept as quasi-standalone applications inside the Translators folder (located in the Symantec C++ folder). This goes for the C, C++, and rez compilers, as well as the .o converter. When the user tells Think Project Manager to compile a file, TPM looks at the files extension (such as .cp for a C++ file), and launches the appropriate compiler (or translator, as Symantec calls them). This is documented in the Symantec manuals.
What isnt documented, however, is the process by which TPM launches the translators. As it is shipped from the factory, when TPM is launched, it turns around and launches the C++ translator and keeps it in memory. The C translator is left on the disk, and called when necessary. This works great if you do most of your work in C++. But if youre like me, and work mostly in C, this slows down the compilation process because every time a C file is to be compiled, the C translator must launched and loaded into memory, while the C++ translator sits there in memory with nothing to do.
Whats a C user to do? Simply modify the C and C++ translators to work the way you want them to. Using ResEdit (or resource editor of your choice), open INFO resource number 0 in the translator named Think C (Symantec graciously includes a ResEdit template for this). Change the setting of Memory Resident Translator? from 0 to 1. Close and save your changes. Voila! The C translator will now be loaded and kept in memory by TPM when it is launched. In one simple step, C compiles are now speeded up. The more files that are being compiled, the greater the speed increase. For instance, a one-file compile is not speeded up much, but if youre working with large projects, the speed increase can be significant.
If you want to free up some memory, you can also modify the C++ translator (named Symantec C++) to not be memory resident.
- Chris Hawk
San Francisco, CA