I tried that but it did not seem to remove the assets that were obtained using the action. I'll try it again.

Thanks, I'm trying to manage working memory with image. With the last question, I am looking at loading an image immediately via a URL and later replacing it with one I have downloaded with the download tag. I just wanted to make sure all of this image swapping is handled by the engine and I don't have to explicitly release the memory before loading a new image.

One last question then, is once the wire engine is loaded, approx how much memory is there available?

Thanks, but I develop on a PC! Not quite the sort of answer I was looking for although I realise it's quite a broad question.

I have some more specific memory questions then:

Does downloading an image (using download) use the full memory of the image or does it stream into storage?

When loading an image, does suppress=yes load the image into memory then unload it?

Does assigning the property suppress=yes unload an image if it is already loaded?

Does changing the source property on an image unload the previous image and load the new image? or should you use unload, then load?

If I change an image with load, does it unload the previous image and release the memory?

If you create an image using the URL parameter and then later assign a new image using source, does the memory get released for the URL image?

Thanks, as it turns out I found a more efficient way do accomplish what I was trying to do given this behaviour!

Thanks Ian,

I tried using the pixel dimensions for each orientation as well, but got the same result.

Richard

Hi Ian,

I have invited you, the project is called iPhone Landing. Its not the padding, just the calculation of the pixels for the size of the images in the different orientations when using a % for image size.

What I am experiencing is similar to the reported behaviour in the Panel object, only for images:

It probably should be noted that if a % is used for a padding value and the app supports landscape and portrait modes, then layout may not be quite as expected when rotating the device.
When using a % for padding, the equivalent number of pixels is calculated once when the panel is first rendered based on the dimensions of the panel at that time. If the device is rotated to portrait/landscape mode, the same number of pixels is used – i.e. the padding is not recalculated.
This is an issue if the panel dimensions are different pixel sizes in portrait and landscape modes, because if the app is started in portrait mode the padding will end up being a different size than if the app is started in landscape mode.

I removed one of the width and height as you suggested. It is an improvement.

Sorry I must be missing something fundamental. I have tried all sorts of combinations of height, lheight, and the just width and lwidth. My images are the correct width and height for portrait and landscape.

The starting images are perfect. When I rotate, it seems the images dont display in the correct aspect ratio. It's like the wire does not re-calculate the % into pixels on rotation. It is more pronounced when I take that same example and start landscape:



That is perfect. When I rotate, the images change, but its like its keeping the landscape ratio:



Squashed on the horizontal now.

I have used widesource in the example, the problem is that the widesource image takes the pixel dimension of the source image.

Portrait:


Landscape: