Ken, thanks for the response.
I have a requirement to download GIFs over a TCP/IP connection, decode them and
display them on the Palm for a GIS system. The GIFs are 400 x 265, which means I'm
looking for some pretty good compression. I don't have the option of creating/storing
Palm bitmaps on the server. I'll tell you more offline if you like.
I chose ScrCompressScanLine because I could figure out what it did from the 3.0
sources. My problems are coming from trying to display the bitmap. I'm testing with
a GIF that creates a bitmap < 60k. I can display it without compression without a
problem. The compression is what is tripping me.
ScrCompress sounded interesting, but since it is a PalmOS 3.5 system-only call I
wasn't sure what it did. I will fall back and try that today.
Thanks
trib
--------------------------------------------------
David Tribble, INRI Hawaii
(808) 625 2118 (v) (808) 625 6315 (f)
-----Original Message-----
From: Ken Krugler [SMTP:[EMAIL PROTECTED]]
David,
Right...250x250x1 byte/pixel is approximately 64K, thus you're
running up against the max chunk size limit.
1. There are definitely some parts of the OS that assume compression
of color bitmaps will be RLE, but I don't know if that's the problem
you're running into.
2. Normally one would use BmpCreate/BmpCompress (available in 3.5),
but that doesn't solve your 64K limit problem, and all of the data
has to be in the dynamic heap - which might be a problem for big
color bitmaps.
3. So then one solution would be to use
ScrCompress(BitmapCompressionTypeRLE, ...) to compress scanline by
scanline. But a question would be why you're compressing on the
device?
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
