Related Info: Color Quickdraw

Tips &Tidbits

By Scott T Boyd, Editor

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 that’s 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

Not Such A Drag After All

The drag manager is really cool and can make apps a lot more intuitive, but it’s a pain to debug since process switches are disabled while drags occur. Since both Think C’s and Metrowerks’ debugger require these, you cannot use them. Never fear! You can use The Debugger!

While we’re on the subject, here’s a gotcha for you. Watch out for a bug that causes deadlock if you call WaitNextevent from a drag receive handler.

- Rod Magnuson,

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 file’s 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 isn’t 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 you’re 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.

What’s 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 you’re 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