Actually it is just a single bitmap. I was just attempting to declare as
few variables as possible. Execution speed is not much of an issue.
Thanks
-----Original Message-----
From: Mike Pellegrino <[EMAIL PROTECTED]>
To: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]>
Date: Thursday, April 15, 1999 4:16 PM
Subject: MemPtrRecoverHandle performance
>Dave,
>
>This reminds me of something when I was working on the virtual memory
>manager. How fast are MemPtrX routines when they have to
>reverse-engineer the handle from the pointer (e.g.,
>MemPtrRecoverHandle)? Is there a direct table lookup going on or is
>there a linear search going on? I tried both ways and I wasn't thrilled
>with my performance given the fact that my lookup tables are in storage
>ram. So I stripped out all VMMPtr routines for the 1.0 release pending
>some algorithmic epiphany which I have not yet had.
>
>Thanks,
>
>Mike
>
>> -----Original Message-----
>> From: David Fedor [SMTP:[EMAIL PROTECTED]]
>> Sent: Thursday, April 15, 1999 2:48 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Is this legal?
>>
>> >BitmapPtr bitmapP;
>> >
>> >bitmapP = (BitmapPtr) MemHandleLock(DmGetResource('Tbmp',1300));
>> >WinDrawBitmap(bitmapP,X,Y);
>> >MemHandleUnlock(DmGetResource('Tbmp',1300);
>> >
>> >Specifically do I need to assign the result from DmGetResource to
>> VoidHandle
>> >or will it work as is. So far it compiles and runs correctly.
>>
>>
>> This is fine, but more efficient (and less code) would be to replace
>> the
>> last line with
>> MemPtrUnlock(bitmapP);
>>
>> More correct code would be to add a line which calls DmReleaseResource
>> on
>> the original handle. So far that isn't necessary, but I shudder to
>> think
>> how many apps would have trouble if it was in fact made necessary.
>>
>> -David Fedor
>> Palm Developer Support
>>
>>
>
>
