ZLauncher backgrounds

Archived from groups: comp.sys.palmtops.pilot (More info?)

I'm using ZLauncher on my Treo 650. I have a jpeg that I've resized
for use as a background in ZLauncher, and it does work as-is. But I
was wondering if there was any way to convert it to a Palm-native file
and still be used.

The jpeg, on my SD card, is 33k, but copied into the internal memory
it's converted to 209k! Plus, it takes a moment or two for ZLauncher
to read the jpeg, and I'd like to speed that up.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"Nobody wants to fight a war unless they know there's at least a chance
of winning. You can give them that hope. As one of the older races,
your technology has to be at least as good as the Shadows. Now, if you
can convince your government to send out an expedition to engage one or
two of their ships..." "...No." (Capt. Sheridan and Amb. Kosh, B5
"Interludes and Examinations" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that AaronJ claimed:

; >The jpeg, on my SD card, is 33k, but copied into the internal memory
; >it's converted to 209k!
;
; Wonder what you're using to copy it. I just copied a 23K jpeg from my card to
; internal memory using the included Media app (Zire 72) and it was still 23K in
; internal memory...

ZLauncher. The jpeg is on the card in
/palm/programs/zlauncher/backimage. Selecting it from within ZLauncher
causes ZLauncher to copy it to RAM. If I de-select it, ZLauncher
removes the copy from RAM.

ZLauncher does not find a jpeg on the internal memory, only on the
card.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"They taught the younger races, explored beyond the rim, created great
empires. But to all things there is an end." (Amb. Delenn, B5 "In The
Shadow Of Z'Ha'Dum" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that AaronJ claimed:

; Well then, I imagine ZLauncher has a reason for making such a large file. It

Hence why I want to convert it to a Palm native format.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"Oh, by the way, you know what they say Narn taste like?" "Yeah. Like
chicken. Man, I really need a vacation." (Dr. Franklin and Mr.
Garibaldi, B5 "Legacies" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

AaronJ wrote:
> Jeffrey Kaplan <cspp@gordol.org> wrote:
>>It is alleged that AaronJ claimed:

>>; Well then, I imagine ZLauncher has a reason for making such a large file. It

>>Hence why I want to convert it to a Palm native format.

> I think we're going in a circle here. You could convert a jpeg file to a Palm
> native format file (pdb) simply by using the Media app like I did and it will
> create a like sized pdb file that contains the jpeg image in internal memory.
> That file can be used by Media as well as the Palm Launcher. But... I doubt that
> ZLauncher could see or use it. Unlike a jpeg file which is a universally
> understood specialized graphics file, the pdb file can contain *anything*.

Just want to point out that Palm OS supports "File Stream" PDBs. They
are basically a standard way of encapsulating any file into a PDB.
A Palm application can then read it in a way that's similar to how
regular applications (those that run on traditional general-purpose
computers) read a file.

It would thus be possible to convert a JPEG into a PDB in a standard
way that preserves the regular structure of the JPEG file. One could
easily do this with the "par" command line utility, like this:

par c -a stream Whatever.PDB Whatever tttt cccc Whatever.jpg

That command says to put the file Whatever.jpg into the PDB file
Whatever.PDB, to name the database "Whatever" (so that it will show
up as that on the Palm, which never sees the "Whatever.PDB" filename),
and to put 'tttt' as its type and 'cccc' as its creator.

Having said that, just because you can put the JPEG into a PDB in
a standard way does not mean that ZLauncher supports that. In fact,
based on this discussion, it seems like it doesn't.

On that subject, it seems like the original poster wishes for a way
for ZLauncher to convert this JPEG into a Palm-native format, in order
to prevent it from taking up much space. However, it's quite possible
that this is exactly what ZLauncher is, in fact, doing -- converting
the JPEG (an efficient file format) into a native file format. The
Palm image format (a Palm Bitmap) has several different options for
compressing image data, and none of them are anywhere near as
efficient as JPEG is. However, the Palm can draw its native image
format much more quickly than it can draw a JPEG. So, I wouldn't
be surprised if the ZLauncher author has chosen to convert the JPEG
into a native-format Palm Bitmap in order to get the drawing speed
they want.

I especially would not be surprised to hear that considering one
other little fact: when you have a Palm Bitmap that is 320x320
(the size of the scren on the Zire 72) and using 16-bit color
(the color depth that the Zire 72 uses), it will take up 204800
bytes plus a little overhead to store the dimensions and other
info about the bitmap. Since it will have to be broken apart to
be stored in a PDB on the device (since records within a PDB can
only accomodate 64K each), that will add a little more overhead,
and I would not be surprised at all if it worked out to 209K, since
that amounts to 4.5% overhead, which is about what you'd expect,
if you take the approach of expanding the JPEG into an uncompressed
bitmap and putting that in the storage heap (a/k/a "internal memory" )
of the Palm.

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that Logan Shaw claimed:

; On that subject, it seems like the original poster wishes for a way
; for ZLauncher to convert this JPEG into a Palm-native format, in order
; to prevent it from taking up much space. However, it's quite possible

Whether the conversion is done by ZLauncher automatically, or by me
preemptively, I don't care. I want to have the file converted so that
it takes up less space in main memory, and also hopefully get rid of
the slight delay that occurs when switching to the launcher when the
image is configured as the background. When no image is configured as
a background, switching to new ZLauncher is instantaneous. My
conclusion therefore is that there's a slight delay while it reads the
file. This delay is probably twofold: translating the JPEG and then
reading it.

; I especially would not be surprised to hear that considering one
; other little fact: when you have a Palm Bitmap that is 320x320
; (the size of the scren on the Zire 72) and using 16-bit color
; (the color depth that the Zire 72 uses), it will take up 204800
; bytes plus a little overhead to store the dimensions and other
; info about the bitmap. Since it will have to be broken apart to
; be stored in a PDB on the device (since records within a PDB can
; only accomodate 64K each), that will add a little more overhead,
; and I would not be surprised at all if it worked out to 209K, since
; that amounts to 4.5% overhead, which is about what you'd expect,
; if you take the approach of expanding the JPEG into an uncompressed
; bitmap and putting that in the storage heap (a/k/a "internal memory" )
; of the Palm.

Well, that's technical information I did not previously have. By the
way, this is on the Treo 650. Our displays set of similar resolutions,
but I don't know about our memory structures. The Treo 650 uses a file
system with larger blocks than most other Palm units. The 24 MB of
memory available to the user is roughly equivalent in total storage
capacity to the 16 MB on my previous Palm.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"I warn you Mariel, do not be overconfident. If I were married to
Londo Mollari I'd be concerned." "G'Kar, if you were married to Londo
Mollari, we'd all be concerned." (Amb. G'Kar and Mariel, B5 "Soul
Mates" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan wrote:
> Which would render it unusable for my purpose wouldn't it? And in any
> case, the media manager that came with my Treo 650 doesn't convert
> JPEG's to Palm native. The Treo appears to have three types of
> internal memory: ROM, regular memory, and media memory. Image files
> that I do import into the internal memory, or make with the built-in
> camera, cannot be located with a file manager.

The Palm actually has only two types of long-term memory (if you don't
count ROM). There is VFS, which means filesystems (like a regular DOS
FAT filesystem) located on SD Card, on internal flash "drive", or (as
in the case of the LifeDrive) on internal hard drive. VFS is what most
file managers let you see.

Then there is also the storage heap. This is the "internal" memory
where your PDB and PRC databases are kept. In the old days (before
memory stick and SD Card), Palms had only storage heap and nothing
else. Storage heap is traditionally a fixed portion of (battery-backed)
RAM, but on newer devices (T5 and Treo 650, and LifeDrive, I think),
storage heap is on flash, but there are special tricks going on behind
the scene to load pieces of it into RAM on demand so that applications
still think of it as residing in RAM.

If you store a regular file, say foo.jpg, in storage heap, it gets
put into what's called a File Stream. A File Stream is really a PDB,
but it has a special flag set that tells the operating system that
it can be treated like a file.

Now, here's the tricky and weird part: the mechanisms for accessing
VFS files and File Stream files are totally different. The two types
of files exist in different locations, they have different types of
filenames (the File Stream world has no hierarchy and does not include
directories -- everything is in a flat namespace). Thus, it's common
to see applications that can read only one type of file and not the
other. It's most common to see applications that only know how to
deal with VFS files and not File Stream files.

The point of all this is that it's possible that the media manager
knows how to write to both VFS files and File Stream files, whereas
the File Manager may only know how to deal with VFS files. Thus,
it would be possible for the media manager to create a type of
file that the File Manager doesn't even know about.

For what it's worth, the freeware FileZ application knows about both
types of files, so if you are interested in investigating, that might
be a good tool to investigate with.

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan wrote:
> It is alleged that Logan Shaw claimed:
>
> ; The point of all this is that it's possible that the media manager
> ; knows how to write to both VFS files and File Stream files, whereas
> ; the File Manager may only know how to deal with VFS files. Thus,
> ; it would be possible for the media manager to create a type of
> ; file that the File Manager doesn't even know about.
>
> I doubt that. I use McFile, and have been for quite a while, long
> before I started using the Treo. And the Treo is the first device I've
> used that has this multiplicity of memory types. Before, I've only had
> "internal ram" ("Palm card" ) and the expansion card (SD or MS).

Oh, I thought you were talking about some sort of built-in file manager,
and since I don't have a Treo 650, I'm not familiar with what applications
come with it, and was just assuming that this hypothetical file manager
only understands VFS.

Since you're talking about McFile and FileZ, that makes me think
that the media manager is instead putting its data into the hidden
VFS filesystem that the Treo 650 and the T|T5 have.

It's a little confusing, but the storage heap (which is, on older
devices, always entirely in RAM) is stored on flash, and that is
done by layering the storage heap on top of a hidden VFS volume.
Volumes are hidden if they have the vfsVolumeAttrHidden attribute
flag set.

So, in the case of a T|T5, you can actually have 3 VFS volumes.
You have the "Internal" VFS volume, which is easily visible
to the user. You have an SD Card VFS volume (if you've got an
SD Card inserted). And, you have a third hidden VFS volume
which is used to store everything in the storage heap. (PRCs
and PDBs are stored as files.)

I guess this leaves me wondering: does FileZ allow you to view
hidden volumes? I haven't downloaded the latest in a while, so
I'm not sure if it does or not.

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan <cspp@gordol.org> wrote:

>ZLauncher does not find a jpeg on the internal memory...

No program will find a jpeg file in internal memory because you can't have a
jpeg file in internal memory. Only pdb or prc files will work in internal
memory. After thinking about it, perhaps ZLauncher will only see it's own
converted jpeg files, and not one converted by another program. If that's the
case I suspect you're SOL on finding a different program to make a smaller
converted jpeg file...

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that AaronJ claimed:

; No program will find a jpeg file in internal memory because you can't have a
; jpeg file in internal memory. Only pdb or prc files will work in internal
; memory. After thinking about it, perhaps ZLauncher will only see it's own
; converted jpeg files, and not one converted by another program. If that's the
; case I suspect you're SOL on finding a different program to make a smaller
; converted jpeg file...

Oh, sorry... ZLauncher support got back to me on this. Paraphrased,
they said that the copy placed into main memory has been converted by
ZLauncher into a Palm-native state, and that since jpg is a compressed
file, it has to be uncompressed to be used.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"Find what you need and let's get out of here. We're running out of
time." "Cannot run out of time. There is infinite time. You are
finite. Zathras is finite. This... is wrong tool. No, no, not good
no... no never use this." (Cmdr. Ivanova and Zathras, B5 "War Without
End Pt. 2" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan wrote:
> It is alleged that Logan Shaw claimed:
>
> ; > After thinking about it, perhaps ZLauncher will only see it's own
> ; > converted jpeg files, and not one converted by another program.
> ;
> ; That's VERY likely to be the case. There is no standard format
> ; for storing converted JPEG files, especially considering that
> ; once decompressed many images will be too large to fit in a PDB
> ; record or PRC resource and therefore some sort of splitting and
> ; reassembling procedure must be used. Each program will choose
> ; its own method. Without cooperation (and there's little motivation
> ; for cooperation), there is no reason one program would be able to
> ; read anothers' converted files.
>
> ZLauncher uses the third party jpeglib.prc, which is included.

Yes, I'm familiar with jpeglib.prc. I first heard about it when it
was released a few months after I had done my own port of the IJG
JPEG library (the same library that jpeglib uses) to Palm OS.

It (and my own port of the same library) both write to a bitmap,
which is data structure that resides in memory. You can call
the library to decode a JPEG, but when you are done, you will
only have a data structure in memory. When your application
exits, that data structure will disappear. If you want to have
the decoded JPEG again, you must make arrangements to save it
and then reload it later.

Unfortunately, a uncompressed 320x320 16-bit Palm bitmap like
you will get back from jpeglib.prc takes a bit over 200K. But
if you wish to save the results in a Palm database, each record
of those is limited to 64K. So, you must choose a scheme for
saving a 200K thing into a 64K space (or spaces). This probably
involves splitting it up. But it could, instead, involve creating
four smaller bitmaps (160x160 each or maybe 320x80) to start with
and storing each of those separately.

The point is, yes, jpeglib.prc is a standard library that many
programs use, and the output of the library is fairly standard.
But that output must be transformed before it can be saved to
persistent storage. I can think of at least 3 obvious different
ways to do this. Which one some developer will pick depends on
that developer's needs. And there is always the chance that they
will decide to store some other data in there as well (making
things further incompatible between programs), since they already
have to write routines to store the decoded JPEG.

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that AaronJ claimed:

; Ok thanks. BTW if you're wondering why I brought this up at this late date, I
; don't exactly know. The post should have gone out a week or two ago when we were
; discussing ZLauncher. Somehow it's been hiding in my newsreader all this time
; and just slipped out last night. I don't understand all I know about this...

Upgrade to a newer version of your newsreader, and if you don't have a
"Post usenet and emails" button on the toolbar, put one there, it
"lights up" when there are messages queued to be sent in the outbox.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"May I have your attention please. In the last few hours we have
learned that warships are coming this way from Earth. Their orders are
to seize command of Babylon 5 by force. As Commanding Officer and
Military Governor of Babylon 5, I cannot allow this to happen." (Capt.
Sheridan, B5 "Severed Dreams" )