hmmm really? When I check memory before I load the fonts and then after, I see a 150K difference..
I'm fairly certain that I'm not copying any data over ( at least for the font) - Just as a note, I'm talking about records that are stored on a card instead of in RAM. I wonder if they are handled differently? I'll also look at my record reader (that I've wrapped around record reads so that both cards and memory 'acts' the same) - and see if I'm caching it. Maybe the system is..? thanks - bill "Dave Carrigan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Thu, Jan 29, 2004 at 11:39:15AM -0800, Fruber Malcome wrote: > > > My question stems off the fact that we have both custom fonts and jpeg > > images in our product. > > The fonts alone take up 150K of the heap (they are stored as data records, > > and then casted for FntDefineFont - since that memory must stay locked until > > use of the font is done, it takes up the memory), I was trying to consider a > > way to store the fonts in such a fashion where I could keep them and not > > lose so much space on the heap. > > This is a little puzzling. Are you making a copy of the record into the > dynamic heap? If so, why? Just lock the record and point FntDefineFont > to the locked record. If you're not making a copy, then why are you > worried? Records in a database use memory in the storage heap whether > they're locked or not; locking them doesn't use any more memory. > > > I'm also trying to think of a way to store the resulting bitmap (from the > > jpeg library) - in such a way where I don't have to keep a handle to it in > > memory (on the heap) so that scrolling down a page is not such a problem. > > Here I'm considering dumping the bitmaps to a temp database as a bitmap > > resource. Then reading the bitmap resource and drawing it only as needed. > > That would remove the requirement of keeping it in heap for such an extended > > period of time as well. (especially since there could be as many as 10 or > > so images on a single page that need to scroll smoothly.) All of which is > > 160x160 and 16bit. > > Use features instead. > > > Unfortunately my efforts to store the bitmap as a bitmap resource in the > > tempDb is failing. I end up with a corrupted image (hence a previous email > > last night). So I really need to see if I can address one or both of these > > issues. > > Features may not solve this problem, but they're still easier to use > than a temp database. We would need to see the code you're using to > store the bitmap to see why it's corrupted. > > -- > Dave Carrigan > Seattle, WA, USA > [EMAIL PROTECTED] | http://www.rudedog.org/ | ICQ:161669680 > UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL > > Dave is currently listening to Clash - Justice Tonight/Kick It Over (Black Market Clash) > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
