I have some questions concerning memory usage. I'm down to 12% free in the emulator and pronto, and I'm only about half done with my programming, so I need to get a handle on any waste. (yes, I realize that there's a feature that performs a cleanup that eliminates deleted stuff hanging around, but this 12% is an initial figure upon emulator startup and download).

1. The statement has been made that the pronto will store a pointer to a bitmap instead of 2 copies of it. How does it know the bitmap is a dup? Does it compare the dimensions and all colors with all bitmaps already created? What happens if a pointer was stored and the source bitmap has been changed, does it then split it into 2 bitmap copies? There's nothing in the documentation about this.

2. If there IS an ability within it to avoid duplicate bitmap storage, what rules does one have to follow to take advantage of it? For example; does it apply to only gallery entries, or any bitmap load? Only ALT copies?

3. Would Philips consider providing a CCF dump utility to show the breakdown of your resulting file so you can help identify and reduce waste?

A followup question....

Do I save any Pronto memory by converting a bitmap to B/W 2 bits or does it not matter?

Keith,

1. ProntoEdit compares the actual bitmap contents to determine if two bitmaps are equal (first it compares the dimensions, if they are equal it compares simple checksums it maintains for every bitmap, and if the checksums are equal it does a pixel by pixel comparison). ProntoEdit does the same thing for IR codes and all strings.

2. When ProntoEdit saves a CCF, it goes through ALL bitmaps to make sure no bitmap is saved twice. It doesn't matter what the bitmap is used for or how you put it in. Again, the same is true for IR codes and strings.

3. Maybe, if I can find some spare time, I may consider doing something like that. Don't hold your breath though... :-)

Regards,

Jan

Keith,

A bitmap which uses only 2 colors is stored as a 1 bpp bitmap, a bitmap which uses 3 or 4 colors is stored as a 2 bpp bitmap. Therefore, you can save memory by reducing the number of colors used in a bitmap. Note that 2 color bitmaps contain a tiny clut so it doesn't matter which colors you pick (i.e. it doesn't have to be black and white).

Something else to consider is that in a CCF the lines in both 1 and 2 bpp bitmaps are padded at the end so they always contain a multiple of 8 pixels (i.e. 8 bit for a 1 bpp bitmap and 16 bit for a 2 bpp bitmap). Therefore you may want to avoid using e.g. 9 pixel wide bitmaps.

Regards,

Jan

Thanks Jan -- that helps a lot. Pretty efficient storage -- I may end up having to eliminate some stuff I was hoping to keep if I run out of memory :-(

One thing that would help a great deal is the ability of specifying a repeat count on an IR action entry -- similar to the way you handle specifying a delay value for a delay entry. Double click the IR command, then specify a repeat count or a "length of time pressed" value.

It would reduce some of my macros from 50 lines to about 5, and increase the functionality of some commands (like "X10 dim lights" or "volume up/down").

Sometimes to get your equipment into a "known/pridictable" state, you end up with a fair amount of wasted commands.

Another big memory (and time) saver would be to be able to specify that the "selected" icon is just a color inverse of the "unselected" icon. There would be no need to store an actual bitmap for that, and I wouldn't have to create inverse copies of all my bitmaps.

Hmmm... probably not just a simple inversion, since the whole rectangle would turn black, which would look odd for a shaped button (a circle, say). Perhaps just rotate the non-white colors, so the button's appearance would change. Essentially the bitmap would simply be drawn with another CLUT - perhaps even make it user-editable.

I'd also like to see other alternative 'automatic' selected appearences, like a 1-pixel black border drawn around the bitmap, for example.