Hi Peter, > From: [EMAIL PROTECTED] > 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. _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
