> Then what's the maximum width of an image? I've loaded a 2000x30x8bpp
> (60K) image and it displays well. It's just an image record, i.e. not an
> embedded image.
More importantly, how do apps like FireViewer and others view images
which are 2000x2000x16bpp on the Palm? What magic are they using to get
around the 64k limitation?
How about if we use the 160x160 (or viewport size on a hires device)
and use that as our "chunk" point in an image. Let's say you have a 320x320
image you want to display. it would look like this (pardon the ascii art):
.--------------.
| .----------. |............
| | | | :
| | chunk 1 | | chunk 2 :
| | | | :
| | | | :
| | | | :
| |__________| | :
|_ _|............
|___________| :
: : :
: : :
: chunk 3 : chunk 4 :
: : :
:...........:............:
If we take what would exist in 'chunk 1' and split that up using
Adam's original format, then do the same (dynamically? blit offscreen?) with
'chunk 2' if they pan left (to move 'chunk 2' left into the "view"), and so
on if they pan up (to bring 'chunk 4' into the "view", ad nauseum. I see
where the issue about splitting images can get into place here, but... this
is a problem at _decompression time_.
What if we stored the images themselves, compressed, at 60k or
whatever the current limit is (based on rle, etc. compression being used)
then apply the chunking part in the _viewer_ and not pre-chunked in the
parser? I see one good reason to do it this way; beamed content.
If I have a hires device, with a 320x320 screen, and parse my
content desktop-side with the modified "chunking parser", and then beam that
content over to someone with a Palm III for example (160x160, low internal
storage memory, etc.) would it not cause problems for them to uncompress and
read that same image? If it was in the viewer, the viewer could check the
device, and "chunk" accordingly.
This is just one idea of course, but obviously it can be done. I've
got huge maps of Boston and New York here on my Palm which pan and zoom fine
in FireViewer and other apps, and the panning/zooming is smooth, very
smooth.
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
