---

GWorlds

When the QuickDraw function NewGWorld allocates storage for the pixel buffer, and the depth parameter is 16 or 32 bits, the byte ordering within each pixel matters. The pixelFormat field of the PixMap data structure can have the values k16BE555PixelFormat or k16LE555PixelFormat for 2-byte pixels, and k32ARGBPixelFormat or k32BGRAPixelFormat for 4-byte pixels. (These constants are defined in the Quickdraw.h header file.) By default, NewGWorld always creates big-endian pixel formats (k16BE555PixelFormat or k32ARGBPixelFormat), regardless of the endian format of the system.

For best performance, it is generally preferable for you to use a pixel format that corresponds to the native byte ordering of the system. When you pass kNativeEndianPixMap in the flags parameter to NewGWorld, the byte ordering of the pixel format is big-endian on big-endian systems, and little-endian on little-endian systems.

You can use the GWorld pixel storage as input to the Quartz function CGBitmapContextCreate or as a data provider for the Quartz function CGImageCreate. The byte ordering of the source pixel format needs to be communicated to Quartz through additional flags in the bitmapInfo parameter. These flags are defined in the CGImage.h header file. Assuming that your bitmapInfo parameter is already set up, you now need to combine it (by using a bitwise OR operator) with kCGBitmapByteOrder16Host or kCGBitmapByteOrder32Host if you created the GWorld with a kNativeEndianPixMap flag. Similarly, you should use kCGBitmapByteOrder16Big or kCGBitmapByteOrder32Big when you know that your pixel byte order is big-endian.

---