Legacy Document
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:
ADC Home > Reference Library > Technical Notes > Legacy Documents > Graphics & Imaging >
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:
|
Color QuickDraw not available to 68000 Macintosh modelsDate Written: 2/4/93 Last reviewed: 3/17/93 Inside Macintosh Volume VI says Color QuickDraw is built into System 7, but
when I use The Color QuickDraw routines were written in 68020 assembly, meaning that only Macintosh models with 68020 and later CPUs have access to Color QuickDraw. Models such as the Macintosh SE, Macintosh Classic, and PowerBook 100 can use only Classic QuickDraw. However, this isn't such a bad thing because the processing power required to run Color QuickDraw would be an enormous burden on the 68000 machines. The bulk of Color QuickDraw routines reside in the larger ROMs of models using the 68020 and greater CPUs, thus taking the burden away from system software. However, if changes have to be made to Color QuickDraw (usually in the form of patches) they reside in system software. Check 'cicn' ID if menu icons are tinyDate Written: 2/16/93 Last reviewed: 7/2/93 The icons that appear in our application's menu lists are very, very small. It looks like they're 8 x 8 (scaled) instead of the standard 16 x 16. Can you tell from our test code why this is happening? This was a wild one! What's causing the weird behavior is that you have a
Color QuickDraw and large pixmapsDate Written: 3/11/93 Last reviewed: 6/24/93 Somewhere in QuickDraw, a routine is using the 14th bit of the This is a long story. It's described in Inside Macintosh Volumes V and VI but we'll summarize it here. Color QuickDraw allows you to pass one of three addresses to Today's applications have trouble with this because they must either refuse to
create pixmaps as big as users want or cause crashes by confusing Engineering is studying future solutions. It's possible that a future QuickDraw
release will support pixmap with a For the present, the solution depends on the conditions under which the problem
affects you. If you're writing an application, the solution could be to patch
Another possibility is to call To recap: The limitation of Animation speed on the MacintoshDate written: 1/18/93 Last reviewed: 4/1/93 How can I get reasonably fast animation on Macintosh models? So far, I've
created off-screen pixmaps with the image and mask, and an extra off-screen
pixmap for use in restoring the original picture. However, You're certainly right that the way to increase performance is by off-screen
drawing and QuickDraw's Just to mention some of the factors that might improve the speed of calling
Whereas QuickDraw often trades performance for flexibility, there are times we'd just as soon trade flexibility for performance. In these cases, we can achieve tremendous gains in speed by writing custom routines to draw to off-screen worlds. I recommend the article "Drawing in GWorlds for speed and versatility" (develop, issue 10) which shows you exactly how to do that. Many developers want to go beyond the speed of QuickDraw. Writing directly to the screen can allow you to create faster animation and graphics than possible with QuickDraw. However, Apple has always maintained that writing to video memory is unsupported, since it may cause your application to break on future systems. If you write directly to the screen, your application will forfeit the use of many Toolbox managers and will put future compatibility at risk. Since most applications require the Window Manager and other basic Macintosh managers, writing to the screen is for only a few specialized applications, such as video games and some animation packages that compete on the quality and speed of graphics. The most important thing to remember is don't write directly to the screen if you don't have to. But if you do need to, an article that provides some guidelines is "Graphical Truffles: Writing Directly to the Screen," develop, Issue 11. Following are some additional articles that animation and game developers find useful:
Also, some sample code that can speed your development is given as SC.015.Offscreen and SC.016.OffSample (Dev CD Jan 93:Technical Documentation:Sample Code: Macintosh Sample Code). Animation on the Macintosh does take some work. Nevertheless, we've seen some pretty amazing animations developed on the Macintosh. Inside Macintosh Volume V PnPixPat & BkPixPat doc fixDate written: 12/4/92 Last reviewed: 3/1/93 Inside Macintosh Volume V (page 103) says that when a PICT pattern
opcode (for instance, 0x0012) comes along, and the pattern isn't a dither
pattern, the full The Inside Macintosh documentation on pages V-103 and V-104 is wrong.
The Pict.r file correctly describes the format of the Disabling Macintosh Color QuickDraw for testingDate written: 9/14/92 Last reviewed: 6/14/93 Is there an easy way to disable Color QuickDraw on a Macintosh? I want to do this for testing our application, to make sure it works correctly on a machine without Color QuickDraw. There's no easy, or perhaps even hard way to disable features built into the system software your particular machine requires. It's designed to work well, not to be toggle-able. Even the hard way isn't a sure thing - trying to patch out all the Color QuickDraw traps could confuse the rest of the system software, which internally may use undocumented routines to accomplish its tasks. The easiest way to test on non-Color QuickDraw machines is to get one. Fortunately, the machines without Color QD are the lowest end of the Macintosh price spectrum - such as the Macintosh Classic, PowerBook 100, and Macintosh SE. You can probably rent or borrow one of these if the prices don't fit your current budget. Using a Macintosh PICT file that's larger than available memoryDate Written: 6/18/90 Last reviewed: 6/14/93 How can I read a 2 MB PICT file into only 1 MB of memory? You can't read it in since you don't have enough memory, but drawing the picture contained in the file using a technique called "spooling" increases your chances of using a 2 MB PICT file with 1 MB memory. Spooling is documented in the Color QuickDraw chapter of Inside Macintosh Volume V (pages 88-89). Getting a single scan line from a PICT fileDate Written: 6/18/90 Last reviewed: 6/14/93 Is there any way to obtain a particular scan line from a PICT file? A PICT file may contain more than just pixmaps, so getting one scan line out of it is not possible. The file may also contain other elements that overlap, such as rects and arcs. The only way to obtain a single line is to draw it off-screen and then, once the whole image is in memory, you can go and study individual pixels. Determining pixel depth from PICT filesDate Written: 6/20/90 Last reviewed: 9/17/91 How do you find out the pixel size of a PICT file on the disk? A picture is by nature independent of depth. For example, you can have a
picture containing On the other hand, if the picture you are looking at has pixmap opcodes in it, then each pixmap contains its own pixel size and in this case a picture can have a number of depths associated with it. If you want to see the pixel size for each pixmap opcode in a picture, replace
all the bottleneck routines and every time the "KnowsPICT," on the Developer CD Series disc, extracts this kind of information. The System 7.0 Picture Utilities package gets this information too. BitMapToRgn for non-Color QuickDraw Macintosh modelsDate Written: 11/9/90 Last reviewed: 6/14/93 Is
Software Licensing Apple Computer, Inc. 20525 Mariani Ave. MS:38-I Cupertino, CA 95014 Phone:(408) 974-4667 Macintosh QuickDraw pixel map stack requirementsDate Written: 12/3/90 Last reviewed: 5/21/91 What are the guidelines for determining how much of an image
Color and non-Color QuickDraw trap dispatch differencesDate Written: 1/28/91 Last reviewed: 6/14/93 Why does a call to The trap dispatcher on Color QuickDraw and non-Color QuickDraw machines are different. If you look at page 89 of Inside Macintosh Volume I, you'll see the toolbox trap word format as it was in the days before Color QuickDraw. Bit 9 was "reserved for future use" and was ignored by the trap dispatcher, and so it was normally set to 0. That means that valid toolbox traps could either look like $A8XX or $A9XX as long as the auto-pop bit was turned off. Color QuickDraw machines have a trap dispatcher that uses that reserved bit to allow for more trap words, and therefore it has a much larger trap dispatch table. Color QuickDraw traps have that reserved bit set, so those traps look like $AAXX or $ABXX. When a non-Color QuickDraw machine tests to see if a trap is implemented or
not, it just checks the trap dispatch table to see if a routine is implemented
for that trap or not. Because the reserved bit is ignored, trap words that look
like $AAXX are treated as equivalent to $A8XX and trap words that look like
$ABXX are treated as equivalent to $A9XX. The trap word for RGBForeColor is
$AA14. If you call If you look at recent DTS sample programs, such as the Utilities sample
(SC.025.Utilities, which you can find on AppleLink in Developer Support and on
the current developer CD), you'll see a routine in Utilities.c called
Under system software version 7.0, the trap dispatcher is modified on non-Color QuickDraw machines so that many Color QuickDraw traps are implemented and work as well as they can in black and white. Macintosh OpenCPicture 72-dpi calculation bugDate Written: 2/12/91 Last reviewed: 6/14/93 The 32-Bit QuickDraw It's a known bug that under Macintosh system software versions 6.0.5 and 6.0.7
with 32-Bit QuickDraw 1.2, GetGWorldPixMap bug and workaroundDate Written: 3/12/91 Last reviewed: 6/14/93 Why does Your analysis of The solution is to use System 7 TextMode problem and workaroundDate Written: 6/12/91 Last reviewed: 8/13/91 Our application uses the The problem you are seeing is due to the use of Using dithering and animation on the same Macintosh imageDate Written: 6/19/91 Last reviewed: 6/14/93 When setting up a dithered grayscale image for subsequent animation (to adjust
brightness, for example), a conflict arises between the use of Palette
animation and the This happens because To work around the problem, you can jump into the bottlenecks and when you see
the PICT hitting the opcode for Rendering color PICTs in a black-and-white environmentDate Written: 7/22/91 Last reviewed: 9/17/91 I want to be able to render a color PICT as a black-and-white image substituting patterns for colors. My images are pretty small and have fewer than 16 colors. What do you suggest as the easiest way? One easy way is to take advantage of 32-Bit QuickDraw and System 7.0's
ditherCopy transfer mode modifier or flag (documented in Inside Macintosh Volume VI, page 17-17).
Call Under System 6 without 32-Bit QuickDraw, the solution is not nearly so cut and
dried. One way might be to take advantage of the fact that Well, this came out as a great sales pitch for writing a System 7-savvy app! Highlighting ignored if foreground same as background colorDate Written: 8/7/91 Last reviewed: 6/14/93 Under System 7, but not System 6, HiliteMode doesn't work when the foreground and background colors are similar. Is this a bug? Yes, it's a bug. The problem you encounter exists whenever the background and
foreground color map to the same color table index. If the foreground color is
the same as the background color, highlighting is ignored. Therefore, you
should always make sure the foreground and background colors are different when
using Gestalt 'qdrw' selector bug and workaroundDate Written: 8/1/91 Last reviewed: 6/14/93 Why does Gestalt tell me I have Color QuickDraw features on a non-Color QuickDraw machine? The GetPixelsState is slow sometimesDate Written: 8/27/91 Last reviewed: 6/14/93 Why do I sometimes see incredible slowdowns under System 7.0 when calling
either
OpenCPicture and PICTs other than 72 dpiDate Written: 10/2/91 Last reviewed: 6/14/93 Can I use __ There's good news and bad news: The good news is that you're on top of the situation, which means the bad news is that there aren't better ways to do what you want to do, mostly. Here's the scoop: You can use (This can work correctly, but the receiving application has to notice
that your picture is bigger than 72 dpi and ask No System 7 QuickDraw alpha channel supportDate Written: 10/23/91 Last reviewed: 6/14/93 How can I directly access the alpha channel (the unused 8 bits in a 32-bit
direct pixel using QuickDraw) under System 7? Under System 6 it was easy, but under System 7's With the System 7 QuickDraw rewrite, all "accidental" support for the unused
byte was removed, because QuickDraw isn't supposed to operate on the unused byte of each pixel. QuickDraw has never
officially supported use of the extra byte for such purposes as an alpha channel. As stated in Inside Macintosh Volume VI, page 17-5,
"8 bits in the pixel are not part of any component. These bits are unused: Color QuickDraw sets them to 0 in any image it creates.
If presented with a 32-bit image--for example, in the Therefore, you cannot rely on any QuickDraw procedure to preserve the contents
of the unused byte, which in your case is the alpha channel. In fact, even
BitsToRgn and MPW BitMapToRegionGlueDate Written: 10/29/91 Last reviewed: 6/14/93 Which version of the system software first contained the call The call To check to see if a system contains 32-bit QuickDraw, you can use the following snippet of code:
If you are using MPW as a development platform, MPW has a library call you can
use that will allow you to use the routine regardless of whether or not 32-bit
QuickDraw exists. The glue routine is called Ensuring even
|
MOVEQ #$19,D0
JSR ([$1524])
|
which for you and me is
MoveQ #25,D0 ; say that memory is full...
_SysError ; and call syserror
|
the line following would be...
What's all this tell you? You have a debugger installed that is rts'ing from
the SysError vector (you aren't supposed to return from SysError normally), or
you have installed your own SysError vector which is rts'ing. At any rate, if
you examine the code directly following the debugger statement and see what it
does, you might imagine the source code looks something like this:
MemFull MoveQ #25,D0 ; say that memory is full...
_SysError ; and call syserror
; If it returns better go into the debugger since its not supposed to return
_Debugger ; Hey! sysError came back!
;
CallNewHand _NewHandle
bne.S MemFull ; could not get the memory, just die
rts
|
What's happening is that you're running out of memory somehow (several places
call MemFull, not just the above place), so you'd need to use a stack crawl to
figure out how you got there. But, the bottom line, QuickDraw has run out of
memory and cannot continue; it tried to put up a system error dialog to tell
the user and for some reason the machine did not get restarted and the SysError
vector returned. You are now in your debugger, since QuickDraw put up the
system error dialog because it could not continue.
Date Written: 5/31/91
Last reviewed: 11/6/91
ditherCopy is not supported on LaserWriters or ImageWriters. On a LaserWriter,
ditherCopy gets misinterpreted and inverts the image. On an ImageWriter it's
treated as a srcCopy. The ImageWriter driver doesn't support color grafPorts,
which is the only way to do the pixel image required for ditherCopy. Use
srcCopy instead for both printers.
Date Written: 1/1/90
Last reviewed: 11/21/90
I'm having trouble using CalcCMask and SeedCFill. What am I doing wrong?
There is some confusion regarding the use of the Macintosh Color QuickDraw
routines CalcCMask and SeedCFill, which are analogous to the older CalcMask and
SeedFill. Much of the confusion was caused by early documentation errors. Be
sure you have the release version of Volume 5 of Inside Macintosh and
version 2.0 or later of the MPW interface files.
The correct interface for CalcCMask is:
PROCEDURE CalcCMask(srcBits, dstBits: BitMap;
srcRect, dstRect: Rect;
seedRGB: RGBColor;
matchProc: ProcPtr;
matchData: LongInt);
|
The correct interface for SeedCFill is:
PROCEDURE SeedCFill(srcBits, dstBits: BitMap;
srcRect, dstRect: Rect;
seedH, seedV: INTEGER;
matchProc: Ptr;
matchData: LongInt);
|
Each routine calculates a one-bit deep bitmap representing either the mask or the fill area depending upon the routine. In both cases, the source bitmap may be either a bitmap or a pixmap, but the destination must be a bitmap, because it must have a depth of one-bit.
It is difficult to pass a pixmap for the source parameter because of Pascal's type checking. To get around this difficulty, you can declare a new type:
then use it to coerce the pixmap as follows:
If you have a PixMapHandle, do the following:
If you are using a grafPort (or a window), you can pass myWindow^.portBits and
not have to worry about whether the port uses a bitmap or a pixmap.
Most of the other parameters are explained in detail in Inside
Macintosh. To use the matchProc and the matchData parameters, though, you
need more information.
As stated in Inside Macintosh, the matchProc parameter is a pointer to a
routine that you would like to use as a custom SearchProc. To better understand
how this is used, it is helpful to know how SeedCFill and CalcCMask actually work.
Both routines start by creating a temporary bitmap which, by definition, is one
bit deep. The source pixmap (or bitmap) is then copied to the temporary bitmap
using CopyBits. This copy causes the image to be converted to a depth of
one-bit. Now with a normal black-and-white image, the standard CalcMask or
SeedFill routine is used to generate the destination bitmap.
Most of the real work is done in the original call to CopyBits, which maps the
pixmap image to a monochrome bitmap equivalent. For each color in the source
pixmap, CopyBits will map it to either black or white. Which colors map to
black and which ones to white is determined by the SearchProc.
SeedCFill installs a default SearchProc that maps all colors to black except
for the color of the pixel at (seedH,seedV). SeedFill then calculates as usual
the fill mask for the white bits.
The default SearchProc for CalcCMask maps all colors to white except the color
passed in the seedRGB parameter. The seedRGB parameter, then, would be the
color of the item that you wanted to "lasso."
But suppose you want to fill over all colors that were shades of green, not
just the particular shade of green at (seedH,seedV). Or maybe you want to fill
over all colors that are lighter than 50 percent brightness. Or maybe you want
to use dark colors as edge colors for CalcCMask. To do such things, you need to
pass a pointer to your own SearchProc in the matchProc parameter.
Because your matchProc is just a custom search procedure for the Color Manager,
it should be declared as one, but Volumes I-V of Inside Macintosh have
documented this routine incorrectly. The correct declaration for a custom
SearchProc is as follows:
FUNCTION SearchProc(VAR RGB: RGBColor;
VAR result: LongInt) : Boolean;
|
Normally, as each SearchProc is installed, it is added to the head of the
SearchProc chain, so that it is called before all of the other ones that were already installed.
When a SearchProc is installed, it can do one of three things:
SearchProc returns TRUE;In cases 1 and 3, the Color Manager continues down the SearchProc chain until
it finds one that returns TRUE. If none of the custom routines handle the call,
then the built-in default routine is used. In case 3, you can change the RGB
color that is being matched. For example, if you want all shades of green to
map to pure green, modify the RGB color, then return FALSE, letting the Color
Manager find the index of that green in the color table.
In case 2, you return TRUE to indicate that you handled the call, and you return the color table index in the result parameter. The Color Manager then uses that index. For example, if you want to substitute white for all colors that can't be matched exactly in the color table, then each time you get called you either return the index into the color table of the exact color, or 0 (which is the index for white) for all other colors.
A custom SearchProc for SeedCFill and CalcCMask should always return TRUE
because the default Color Manager SearchProc usually doesn't make sense.
Because SeedCFill and CalcCMask are using CopyBits to copy to a 1-bit bitmap,
you need to set the result to be either 0 or 1 (the only possible values in a
1-bit bitmap). A result of 0 is white, and a result of 1 is black.
All colors for SeedCFill that should be "filled over" would generate a result
of 0 (white), and all colors that stop the fill generate a 1 (black). SeedFill
is then called to fill the white area. All colors for CalcCMask that you want
to form boundaries should generate results of 1 (black).
When your SearchProc gets called, the gdRefCon field of the current GDevice
(theGDevice^^.gdRefCon) contains a pointer to the following record:
matchRec = RECORD
red: Integer;
green: Integer;
blue: Integer;
matchData: LongInt;
END;
|
The red, green, and blue parameters for SeedCFill are the values of the color
of the pixel at (seedH,seedV). For CalcCMask, they are the fields from the seedRGB parameter.
Your SearchProc can use this information to decide which colors are "fill-over" colors and
which colors are "boundary" colors. For example, if you always set (seedH,seedV) to be
the mouse point, your SearchProc then bases its decisions using the color of the pixel
under the cursor. For example, the user clicks a shade of green, so all shades of
green get filled over.
The matchData field contains the value that you passed into the SeedCFill or
CalcCMask routines in the matchData parameter. The use of this field is
completely user-defined. For example, since your SearchProc routine may be a
separate module, you might want to use this field to pass a handle to your
variables. This field can contain a handle, a pointer, a long integer, or
whatever; or you can just ignore this field altogether.
|
Warning: |
CalcCMask and SeedCFill both use a parameter set that is very similar to the
one used by CopyBits. CalcMask and SeedFill, however, are a different story.
Instead of passing bitmaps and rectangles to SeedFill and CalcMask, these
routines use an unusual set of parameters that describe the memory to be
operated upon in terms of pointers, height, width, and offsets to the next row
(rowBytes). Although these parameters are fairly easy to calculate, there are
some limitations.
The most restrictive limitation is that the width of the rectangle used must be
an even multiple of 16 bits. This limitation exists because the width of the
rectangle is passed to SeedFill and CalcMask as a number of words (2 bytes).
When calculating this parameter, SeedCFill and CalcCMask round down to an even
word boundary. This rounding means that the rectangles you pass to CalcCMask
and SeedCFill should be an even multiple of 16 pixels in width. If they are
not, then the rightmost portion of the mask will be garbage.
To figure out the color of the pixel at (seedH,seedV), SeedCFill calls
GetCPixel. GetCPixel finds the color of the pixel at (h,v) in the current port.
Therefore, if you pass a pixmap that is not the pixmap of the current port you
will get bizarre results. In other words, seedH and seedV are expressed in the
local coordinates of the current port, not the coordinate of the source pixmap.
You have two methods to make it work. First, always pass the pixmap of the
current port as the source parameter. If you are using an off-screen pixmap, it
is a good idea to have an associated port for it, and then call SetPort,
passing it a pointer your off-screen port, before you call SeedCFill.
The second method involves letting SeedCFill get some wrong value for the color
at (seedH,seedV) then using your own custom SearchProc to do the real work. The
default SearchProc for SeedCFill relies on getting the correct color, but your
SearchProc doesn't have to.
SeedCFill also makes the assumption that the seedH and seedV parameters are in
the local coordinate system of the destination bitmap. This assumption comes
into play when SeedCFill calculates the seedH and seedV parameters for SeedFill.
All this means that SeedCFill only works correctly if the source pixmap,
destination pixmap, and current port all use the same coordinate system.
Because of the above problem, this is almost automatic since the current port's
portRect and the bounds of the source pixmap have to be the same anyway.
The easiest way to make all this work is to have your main port be an even multiple of 16 pixels wide. Then, make sure that your source and destination structures (pixmap or bitmap) are all the same size and all have origins of (0,0).
Date Written: 1/1/90
Last reviewed: 6/14/93
Is there a general file format for color pictures that is common to all of the color paint programs? If so, where is it documented?
Apple supports (and encourages developers to support) one file type for pictures: the PICT file type. Most paint-type programs handle PICT files.
A PICT file is composed of two parts in its data fork; the first 512 bytes are for the file header, which contains application-dependent information. You have to contact the individual publishers to find out their particular data structures. For example, you can contact Claris Technical Support at AppleLink CLARIS.TECH or (415) 962-0371 for the file header MacDraw writes to its files.
The rest of the data in the file is picture data as created by Macintosh QuickDraw with OpenPicture. You can find the information about this data in Volume V of Inside Macintosh (pages 84-105); this section also shows how to read/write PICT files.
You can also check the Macintosh Technote "Displaying Large PICT Files" for more details on the subject.
X-Refs:
DTS Macintosh Technical Note "QuickDraw's Internal Picture Definition"
DTS Macintosh Technical Note "Displaying Large PICT Files"
Date Written: 1/1/90
Last reviewed: 11/21/90
I'm drawing into a large off-screen bitmap (pixmap), but anything drawn outside the 640- by 480-pixel Macintosh screen area doesn't get written to the pixmap. Why not?
When you create a new port with OpenPort or OpenCPort the visRgn is initialized
to the rectangular region defined by screenBits.bounds (IM I:163). If your port
has a large portRect, any drawing will be clipped to the visRgn and you will
lose any drawing outside of the screenBits.bounds rectangle.
To correct this set the visRgn of the port to coincide with your port's
portRect after creating the port.
Also note that OpenPort initializes the clipRgn to a wide-open rectangular
region (-32768, -32768, 32767, 32767). Some operations, like OpenPicture, can
fail with this setup, so try setting clipRgn to a smaller rectangle.
X-Refs:
DTS Macintosh Technical Note "Pictures and Clip Regions"
DTS Macintosh Technical Note "Drawing into an Off-Screen Pixel Map"
Date Written: 1/1/90
Last reviewed: 6/14/93
We want to use OpenCPicture for higher resolution, not for color per se. Can
OpenCPicture in System 7 be used with non-Color as well as Color QuickDraw
Macintosh computers?
Yes, with System 7, OpenCPicture can be used to create extended PICT2 files
from all Macintosh computers. Under System 6.0.7 or later, you must test for
32-Bit QuickDraw before using OpenCPicture. You can do this by calling Gestalt
with the gestaltQuickdrawVersion selector. If it returns gestalt32BitQD or
greater, then 32-Bit QuickDraw is installed.
Date Written: 1/1/90
Last reviewed: 6/14/93
How can my program find out which version of Macintosh 32-Bit QuickDraw is running?
The following code snippet demonstrates how to use the Gestalt Manager to
determine which version of 32-Bit QuickDraw is installed. There is no way to
determine the version of 32-Bit QuickDraw before Gestalt. For 32-Bit QuickDraw
version 1.2, Gestalt returns 2.2. Inside Macintosh Volume VI describes
the Gestalt Manager in detail.
#defineTRUE0xFF
#defineFALSE0
#define Gestalttest0xA1AD
#define NoTrap0xA89F
main()
{
OSErrerr;
longfeature;
if ((GetTrapAddress(Gestalttest) != GetTrapAddress(NoTrap))) {
err = Gestalt(gestaltQuickdrawVersion, &feature);
if (!err) {
if ((feature & 0x0f00) == 0x0000)
printf ("We have Original QuickDraw version 0.%x\n", (feature & 0x00ff));
else if ((feature & 0x0f00) == 0x0100)
printf ("We have 8 Bit QuickDraw version 1.%x\n", (feature & 0x00ff));
else if ((feature & 0x0f00) == 0x0200)
printf ("We have 32 Bit QuickDraw version 2.%x\n", (feature & 0x00ff));
else
printf ("We don't have QD\n");
}
else
printf ("Gestalt err = %i\n",err);
}
else
printf ("No Gestalt\n");
}
|
Date Written: 1/1/90
Last reviewed: 12/7/90
Under what System 7 and System 6 conditions is it legal to call the Macintosh QDError function?
Under System 7, QDError can be called from all Macintosh computers. (System 7
supports RGBForeColor, RGBBackColor, GetForeColor, and GetBackColor for all
Macintosh computers as well.) On a non-Color QuickDraw Macintosh, QDError
always returns a "no error." Under System 6, QDError cannot be used for
non-Color QuickDraw Macintosh systems.
CopyBits transfer modes changed for System 7Date Written: 1/1/90
Last reviewed: 6/14/93
Why do some Macintosh CopyBits transfer modes produce different results for
System 7 than for System 6?
Under System 6, the srcOr, srcXor, srcBic, notSrcCopy, notSrcOr, notSrcXor, and
notSrcBic transfer modes do not produce the same effect for a 16- or 32-bit
(direct) pixel map as for an 8-bit or shallower (indexed) pixel map. With Color
QuickDraw these classic transfer modes on direct pixel maps aren't color-based;
they're pixel-value-based. Color QuickDraw performs logical operations
corresponding to the transfer mode on the source and destination pixel values
to get the resulting pixel value.
For example, say that a multicolored source is being copied onto a
black-and-white destination using the srcOr transfer mode, and both the source
and destination are 8 bits per pixel. Except in unusual cases, the pixel value
for black on an indexed pixel map has all its bits set, so an 8-bit black pixel
has a pixel value of $FF. Similarly, the pixel value for white has all its bits
clear, so an 8-bit white pixel has a pixel value of $00. CopyBits takes each
pixel value of the source and performs a logical OR with the corresponding
pixel value of the destination. Using OR to combine any value with 0 results in
the original value, so using OR to combine any pixel value with the pixel value
for white results in the original pixel value. Using OR to combine any value
with 1 results in 1, so using OR to combine any pixel value with the pixel
value for black results in the pixel value for black. The resulting image shows
the original image in all areas where the destination image was white and shows
black in all areas where the destination image was black.
Take the same example, but this time make the source and destination 32 bits
per pixel. The direct-color pixel value for black is $00000000 and the
direct-color pixel value for white is $00FFFFFF. CopyBits still performs a
logical OR on the source and destination pixel values, but notice what happens
in this case. Using OR to combine any source pixel value with the pixel value
for white results in white, and using OR to combine any source pixel value with
the pixel value for black results in the original color. The resulting image
shows the original image in all areas where the destination image was black and
shows white in all areas where the destination image was white--roughly the
opposite of what you see on an indexed pixel map.
The newer transfer modes addOver, addPin, subOver, subPin, adMax, and adMin
work consistently at all pixel depths, and often, though not always, correspond
to the theoretical effect of the old transfer modes. For example, the adMin
mode works similarly to the srcOr mode on both direct and indexed pixel maps.
Also, 1-bit deep source pixel maps work consistently and predictably regardless
of the pixel depth of the destination even with the old transfer modes.
Under system software version 7.0, the old transfer modes now perform by
calculating with colors rather than pixel values. You'll find that transfer modes like srcOr and srcBic work
much more consistently even on direct pixel maps.
Date Written: 3/3/92
Last reviewed: 6/14/93
I'm calling SetEntries to update the on-screen CLUT. Who implements this call?
Does 32-Bit QuickDraw? In other words, does the 32-Bit QuickDraw INIT need to
be around for this to work? What about monochrome machines?
I'm creating off-screen buffers by hand instead of using GWorlds. Is this the
proper way of doing off-screen buffering when we don't want to require the user
to have 32-Bit QuickDraw?
SetEntries is part of the Color Manager, which exists with all Color QuickDraw
versions. A good rule of thumb to follow is that if it is documented in Inside Macintosh Volume V,
you don't need 32-Bit QuickDraw to use it. Inside Macintosh Volume V documents standard Color QuickDraw.
SetEntries does not work on monochrome Macintosh models, including the Classic II, SE, and PowerBooks.
Off-screen buffering: You should always use GWorlds if they exist; use Gestalt
to test for them. This will assure that you can take advantage of the latest
speed improvements. It is important to remember that under System 7 NewGWorld
and accompanying calls are present in all Macintosh computers including
black-and-white systems such as Classic and PowerBook 100 systems.
rowBytes changeDate Written: 4/22/91
Last reviewed: 6/14/93
The Color QuickDraw section of Inside Macintosh Volume VI states that
the restriction on the rowBytes field in a pixmap has been relaxed from $2000
to $4000. When did this happen? Is it true for all 32-Bit QuickDraw versions?
This affects our user configuration recommendations.
The maximum rowBytes extension to $3FFE or less applies only to 32-bit
QuickDraw. Using pixmaps with rowBytes greater than $1FFE when 32-bit QuickDraw is not present is likely to
cause problems such as garbage images or system crashes. Remember that 32-bit QuickDraw is always
present under System 7.0 or higher.
Date Written: 5/7/91
Last reviewed: 7/25/91
What's the best approach to horizontally flip a 24-bit off-port color pixmap?
Unfortunately, you won't be able to use CopyBits for this kind of procedure;
you'll have to write your own routine to move each pixel. I'd suggest doing this in assembly language to
squeeze the best possible performance out of your code.
Date Written: 4/26/91
Last reviewed: 6/17/91
Why do I have to use GetCIcon(resID) instead of Get1Resource('cicn',resID)
for PlotCIcon to work correctly?
You apparently thought something that, at first, I thought also: that
GetCIcon(resID) is just a utility routine that translates to
Get1Resource('cicn',resID). However, this is not the case; GetCIcon not only
gets the 'cicn' resource, but it also performs some minor surgery on the
results, fills in some placeholder fields in the resource data, and the like.
Basically, PlotCIcon can't work without the things that GetCIcon does.
Date Written: 3/31/92
Last reviewed: 6/14/93
The code I added to my application's MDEF to plot a small icon in color works
except when I hold the cursor over an item with color. The color of the small
icon is wrong because it's just doing an InvertRect. When I drag over the Apple
menu, the menu inverts behind the icon but the icon is untouched. Is this done
by brute force, redrawing the small icon after every InvertRect?
The Macintosh system draws color icons, such as the Apple icon in the menu bar,
every time the title has to be inverted. First InvertRect is called to invert
the menu title, and then PlotIconID is called to draw the icon in its place.
The advantage of using PlotIconID is that you don't have to worry about the
depth and size of the icon being used. The system picks the best match from the
family whose ID is being passed, taking into consideration the target rectangle
and the depth of the device(s) that will contain the icon's image.
The Icon Utilities call PlotIconID is documented in the Macintosh Technical Note "Drawing Icons the System 7 Way"; see this Note for details on using the Icon Utilities calls.
Date Written: 2/11/92
Last reviewed: 6/14/93
When a picture that contains a pixmap is spooled into a window, how and when is the depth of the pixmap in the picture converted to the depth of the screens the window is on?
When a picture is spooled in, if QuickDraw encounters any bitmap opcode, it
allocates a pixmap of the same depth as the data associated with the bitmap
opcode, expands the data into the temporary pixmap, and then calls StdBits.
StdBits is what triggers the depth and color conversions as demanded by the
color environment (depth, color table, B&W settings) of the devices the
target port may span (as when a window crosses two or more screens).
If there's not enough memory in the application heap or in the temporary memory
pool, QuickDraw bands the image down to one scan line and calls StdBits for
each of these bands. Note that if you're providing your own bitsProc, QuickDraw
will call it instead of StdBits.
This process is the same when the picture is in memory, with the obvious exception that all the picture data is present; the color mapping occurs when StdBits does its stuff.
Date Written: 6/10/92
Last reviewed: 6/14/93
In a version 2 picture, the picFrame is the rectangular bounding box of the
picture, at 72 dpi. I would like to determine the bounding rectangle at the
stored resolution or the resolution itself. Is there a way to do this without
reading the raw data of the PICT resource itself?
With regular version 2 PICTs (or any pictures), figuring out the real
resolution of the PICT is pretty tough. Applications use different techniques
to save the information. But if you make a picture with OpenCPicture, the
resolution information is stored in the headerOp data, and you can get at this
by searching for the headerOp opcode in the picture data (it's always the
second opcode in the picture data, but you still have to search for it in case
there are any zero opcodes before it). Or you can use the Picture Utilities
Package to extract this information.
With older picture formats, the resolution and original bounds information is sometimes not as obvious or easily derived. In fact, in some applications, the PICT's resolution and original bounds aren't stored in the header, but rather in the pixel map structure(s) contained within the PICT.
To examine these pixmaps, you'll first need to install your own bitsProc, and
then manually check the bounds, hRes, and vRes fields of any pixmap being
passed. In most cases the hRes and vRes fields will be set to the Fixed value
0x00480000 (72 dpi); however, some applications will set these fields to the
PICT's actual resolution, as shown in the code below.
Rect gPictBounds;
Fixed gPictHRes, gPictVRes;
pascal void ColorBitsProc (srcBits, srcRect, dstRect, mode,
maskRgn)
BitMap *srcBits;
Rect *srcRect, *dstRect;
short mode;
RgnHandle maskRgn;
{
PixMapPtr pm;
pm = (PixMapPtr)srcBits;
gPictBounds = (*pm).bounds;
gPictHRes = (*pm).hRes; /* Fixed value */
gPictVRes = (*pm).vRes; /* Fixed value */
}
void FindPictInfo(picture)
PicHandle picture;
{
CQDProcs bottlenecks;
SetStdCProcs (&bottlenecks);
bottlenecks.bitsProc = (Ptr)ColorBitsProc;
(*(qd.thePort)).grafProcs = (QDProcs *)&bottlenecks;
DrawPicture (picture, &((**picture).picFrame));
(*(qd.thePort)).grafProcs = 0L;
}
|
|
|
Acrobat version of this Note (92K). |
|
