Newcomer trying to create PixMap

[Jim Hague]

I'm working on some code for a 4D plugin. The code must run on Mac
proper (OS9 & OSX, so Carbon) and Win32. The latter is done via Mac2Win,
so the code is completely Mac-style. This is my first exposure to Mac;
I'm usually a Unix/Win32 soul.

The code is simply to display some pixmap graphics. From a library
I am getting a buffer filled with the pixmap content as 32 bit colour
ARGB. I also have the pixmap width and height.

The route I'm taking at present is to build a PixMap directly and CopyBits
it onto the port. This works fine under Mac2Win, but on a real Mac (OSX),
nothing appears. If instead I try filling the target rectangle with red
and writing some text in green I get the expected results, so I've defintely
got the right target rectangle and the right port.

Can some kind soul could provide guidance on

a) anything obviously wrong with the code below,

and/or

b) ways of finding out from QuickDraw what it thinks any problem is.
(QDError() returns 0 after the CopyBits call).

Thanks in advance.

Jim

I'm creating the pixmap thus:

pmh = NewPixMap();
HLock(reinterpret_cast<char **>(pmh));
pmp = *pmh;

pmp->baseAddr = reinterpret_cast<Ptr>(rgba);

// Top bit set means this is a pixmap not a bitmap
pmp->rowBytes = static_cast<short>(width * 4) | 0x8000;

pmp->bounds.left = 0;
pmp->bounds.top = 0;
pmp->bounds.right = static_cast<short>(width - 1);
pmp->bounds.bottom = static_cast<short>(height - 1);

pmp->cmpCount = 3;
pmp->pixelType = RGBDirect;
pmp->pixelSize = 32;
pmp->cmpSize = 8;

pmp->pmVersion = baseAddr32;
pmp->packType = 0;
pmp->packSize = 0;

This is then passed to CopyBits to display on the current port:

CopyBits(reinterpret_cast<BitMapPtr>(pmp),
reinterpret_cast<BitMapPtr>(GetPortPixMap(curPort) ),
&source, &target,
srcCopy, NULL);

Source and target are the source and target rectangles, and are correct.
--
Jim Hague - [email]jim@bear-cave.org.uk[/email] Never trust a computer you can't lift.

[David Phillip Oster]

In article <20030806155558.5729.0.NOFFLE@fluffy.bear-cave.org.uk>,
[email]jim@fluffy.bear-cave.org.uk[/email] (Jim Hague) wrote:

> a) anything obviously wrong with the code below,

> // Top bit set means this is a pixmap not a bitmap
> pmp->rowBytes = static_cast<short>(width * 4) | 0x8000;

rowBytes can't just be whatever you feel like, it must be a multiple of
some power of 2 that I can't remember, for example 64.

[Jim Hague]

In article <oster-93A371.20281506082003@newssvr21-ext.news.prodigy.com>,
David Phillip Oster <oster@ieee.org> wrote:

>> a) anything obviously wrong with the code below,

>

>> // Top bit set means this is a pixmap not a bitmap
>> pmp->rowBytes = static_cast<short>(width * 4) | 0x8000;

>
>rowBytes can't just be whatever you feel like, it must be a multiple of
>some power of 2 that I can't remember, for example 64.

Thats for the suggestion.

The Carbon docs (and IM) say:

rowBytes
The offset in bytes from one row of the image to the next. The value
must be even, less than $4000, and for best performance it should be
a multiple of 4. The high 2 bits of rowBytes are used as flags. If
bit 15 = 1, the data structure pointed to is a PixMap structure;
otherwise it is a BitMap structure.

so it doesn't look like that's the problem.

(Later)

Found it. For the record, the problem turned out to be in the CopyBits() call.

CopyBits(reinterpret_cast<BitMapPtr>(pmp),
reinterpret_cast<BitMapPtr>(GetPortPixMap(curPort) ),
&source, &target,
srcCopy, NULL);

fails. Turn this into

CopyBits(reinterpret_cast<BitMapPtr>(pmp),
GetPortBitMapForCopyBits(curPort),
&source, &target,
srcCopy, NULL);

and it works. As far as I can see, the difference is that the latter passes
a BitMapPtr in while the former passes in a PixMapHandle, so that cast
is a right stuff-up.
--
Jim Hague - [email]jim@bear-cave.org.uk[/email] Never trust a computer you can't lift.

[Mike Kluev]

In Article [email]20030810113743.74B0.2.NOFFLE@fluffy.bear-cave.org.uk[/email], Jim Hague
wrote:

> In article <BB59FE34.1517A%mike@objc-source.-DELETE-.org>,
> Mike Kluev <mike@objc-source.-DELETE-.org> wrote:

>>
>> You didn't define hRes, lowRes, planeBytes, pmTable, pmReserved.
>> I would, for completeness:
>>
>> pmp->hRes = 0x00480000;
>> pmp->vRes = 0x00480000;
>> pmp->planeBytes = 0;
>> pmp->pmTable = NULL; // or GetCTable(8),
>> //if NULL turns out to be a problem
>> pmp->pmReserved = 0;

>
> I didn't define then because NewPixMap() is supposed to copy this stuff from
> the current device's PixMap. Since it's a 32 bit colour image, I assumed
> the colour table was irrelevant, so whatever's there is fine. Maybe I
> should define hRes and vRes, to be on the safe side.

I would clear pixelFormat (planeBytes) and pmExt (pmReserved) because
current device's pixmap might contain something there that you don't
want. As to color table for 32-bit pixmaps, in the dark ages there was
a bug in QuickDraw that would cause a crash if there was NULL color
table (even for direct-color pixmaps). Hopefully it is not there anymore.

> CodeWarrior complained that planeBytes and pmReserved were not members of
> the PixMap structure when I tried setting them.

Because of this:

#if OLDPIXMAPSTRUCT
long planeBytes;
CTabHandle pmTable;
long pmReserved;
#else
OSType pixelFormat;
CTabHandle pmTable;
void* pmExt;
#endif

> Thanks for looking through my fumbling, Mike. Much appreciated.

You are welcome.

--
Mike Kluev

PS. Remove "-DELETE-." part of my e-mail address to reply.