Pros and cons of where to store image data

[Ken Norris]

Hi Peter,

> From: peter9.smith at ps.ge.com
> Subject: Pros and cons of where to store image data
> Date: Tue, 16 Sep 2003 03:48:03 -0400

> Assuming that's correct what are the pros and cons?  If you hold the image
> data inside the card is it compressed in the stack file?  I'd prefer to hold
> the image data inside the card as that should be faster loading the stack.
----------
Yes, I think your assessment is basically correct.

Here's my basic philosophy:

If you have many, say hundreds of images, for display, like, for example, my
intentions to develop a program for storing, updating, and sending to a
website, hundreds (perhaps thousands some day) of aerial photos, then it
makes no sense to import these as controls in a stack. The memory required
to load the stack would be ridiculous, and the work to update/replace the
images, even worse. Such a set of images should probably be kept in a
separate image folder where you can deal with them at option, i.e., without
even having a Rev program open.

OTOH, if I have splash window images, page header images, logos, things like
that, which aren't likely to need replacement anytime soon, I will probably
want them to load with the stack, so I will likely import them.

Icons and similar types of images lie somewhere in between. If each is
unique, you can just import them. Or, if you have several buttons with the
same image icon, then you can refer them all to just one image, which saves
memory. If you have buttons or other objects that switch images often, then
having an image library in a substack would be handy.

To give you a more complex example:

I have been (off and on) designing custom onscreen keyboards. Each of the
keys need to have unique 'up' and 'down' state images, plus I've been
working on a number of separate theme-based designs. For these reasons, I
had hoped to use a large single keyboard in a group and call out rects for
switching states, but it won't work for some keys. Plus, as I said, there
are different theme designs. I think the best solution will be a blend of
ideas, but I'm still struggling with deciding on the best way to store them
to where a user can switch themes, download and open new ones as I create
them, etc. (same with feature plugins).

So, as you can see, the 'pros' or 'cons' for how to handle images can get a
little convoluted. The solution(s) you should use just depends on how you
need to manipulate (or not) your images.

Here's hoping I didn't just confuse you worse...

HTH,
Ken N.