On Wed, Aug 01, 2001, Bernd Sieker wrote:
> Most of the time plucker just complains that there was too little
> memory to extract and display the page or the image, but sometimes
> (on images, whose originals were huge) it locks up and I need to
> soft-reset the PDA.
I would need access to the actual Plucker document to check if the
included image really is 320x240x4 or if it is larger than the
supported size.
> It cannot be a lack of main memory, since I still have about 5 MB
> free, and a fully uncompressed 320x240 4bit images is only about 38k;
Palm OS divides the available RAM into two logical areas: dynamic RAM
and storage RAM. Dynamic RAM is used for temporary allocations, and
can be compared to the RAM you have in a desktop system. The rest of
the available RAM is used as storage RAM and is analogous to disk
storage on a desktop system.
The size of the dynamic RAM (also called dynamic heap) depends on the
OS version and the available physical RAM. I don't know how big the
dynamic heap would be on your Visor, but either way the function used
for the image handling, WinCreateOffscreenWindow, will not be able to
handle images larger than 64k. According to the Palm OS documentation
this function should return an error code if it fails to allocate
enough memory for the image, but if you try to create an offscreen
window that is larger than 64k it will crash the device.
Palm OS is not open source, so the only thing I can do about this
problem is to try to work around it by checking the size of the
image and display an alert if it is found to be larger than 60k
(4k safety margin). If the available heap is smaller than 60k
(from fragmentation, running hacks, etc.) then cross your fingers
and hope it doesn't require a hard reset...
Still, if you include images that are larger than 64k uncompressed
the viewer will crash in the uncompress function. The reason for
this crash is that the size will not fit in the 2 bytes used to
store the size of the uncompressed image, so it will "wrap around",
the viewer will allocate too little space for it and the viewer will
crash when uncompressing the image data. Such documents are not
according to the spec and should be prevented already in the parser.
Might add some better protection (or a different implementation for
the image handling) in the future, but Plucker is not an image viewer,
so it doesn't have that high priority on my list.
/Mike
