I don't have the SDK source in front of me, but I can tell you what I recall.
Creating an Image Resource from an Image object keeps a reference to the Image object in the Resource... and the resource reference sticks around until it is explicitly removed... it's not enough to replace the resource in the view because in theory you might be using that same resource in another view or something. Instead, for that case, call bg.getResource().remove() to free up that memory if you don't need it anymore... if you do need it, then keep a reference to it and re-use it instead of creating new ones.
All the SDK needs
to keep of the Image object is its width/height and the id it gets back from the TiVo...but it doesn't do that ,unfortunately. I tried a couple of things to work around that before (a new ImageResource class that disposes of the image reference... works, but didn't work when I tried to run it under Galleon since it had to be sneaky and call itself part of the SDK's package... the other one was an Image class that disposed of the data after it had been requested once, but the underlying ImageIO conversion classes the SDK uses only support a fixed list of class instances and reject anything else)
The createImage must be sending the image as a stream, rather than as an object.... OR it's modifying a single image resource object (keyed by the name of the file) and not creating new ones. I think it's creating a stream since it's using a file by name.
Anyhow... as you saw, using a file/stream is the best way to go... and in general if you can say getResource("string") it's the best thing to do since the SDK does the right thing and manages the cached resource IDs and reuses them if you use the same string. You can use that for images (local files or URLS), sounds, mp3s (local files or URLS), fonts, and animations...unfortunately you can't use it for text resources, though.
More detail at an older post: http://www.tivocommunity.com/tivo-vb...48#post6701148