ImageLoader and image decompressing when scaling.

[Ideum]

Hello, I'm working on a very simplified pyramid image viewer. The purpose of the class is to take a number of image files, load them in, make the smallest one visible and available to scale, and then every time an image is scaled up or down to the point where it matches or exceeds the dimensions of the next largest or smallest image, the viewer switches the visibility to that image, making it consistently appear as though the image is at its normal screen resolution and has not been resized or shrunk.

 

Right now, I'm using LoaderMax to try and load the images in. I'm able to successfully load them in, store them in an array, and add them to the stage. The problem appears to be when handling the scale event, there is some slowdown, most frequently at the larger image sizes, and quite often a crash.

 

When I observe the application's behavior in Adobe Scout, the DisplayList rendering seems to be taking the lion's share of the processing during the slowdown, and of that, specifically "Decompressing Images" takes the most of the DisplayList Rendering processes.

 

This latency when scaling does not appear to happen when using Flash's default loading processes, but then it's slow and tedious and we're trying to switch our framework to LoaderMax anyway. Is there any reason I'm seeing this weird latency with scaling the images once loading? Does the report that "Decompressing Images" is taking up a lot of processing in Scout point towards the problem? Is this a setting issue that could be changed?

 

I'm using a LoaderMax object to load the queue, and for the ImageLoader I'm giving it a simple LoaderContext where the only property set is "ImageDecodingPolicy.ON_LOAD"

[GreenSock]

Hm, tough to say without doing a lot of analysis on exactly how you're doing things and what's going on in your files, but this sounds like you're pushing the graphics rendering system very hard and making Flash decode a lot of images into memory. Here are some tips:

1. Don't put any images into the display list until you absolutely need them. Dropping them into the display list causes Flash to decode the image and push it into memory. 
2. dispose() loaders/images that you don't need.
3. If you're having LoaderMax do any cropping or if you're defining a container for your ImageLoaders, try NOT doing that but instead, manage that stuff yourself when you actually need the asset(s). 
4. You could use LoaderMax to load everything, and as soon as each image is loaded, you could grab the rawContent and store the Bitmap yourself and then dispose() the ImageLoader. Not that you should normally have to do that - I'm just saying that if you're running into trouble, that's something to try. 

Let us know of something here helps. 

[Ideum]

Thank you for the reply!

 

We weren't doing any cropping, and I found the 4th and 2nd option helping before needing to get to the first.

 

I had already been grabbing the individual bitmaps from the rawContent and storing those in an array which was indexed as a user scaled in and out, so what really helped seemed to be disposing of the individual loaders, and then the whole queue when it finished. I had been waiting for when the image container was cleared for new content to get rid of them, which I suppose was the wrong idea.

 

Now it is functioning properly. Thanks again!

[Ideum]

Well, I hate to be back. The problem was mostly solved, at least for when the application has finished start up. After a period of being left idle, the images which are not on display seem to get re-compressed, so when they're added back to the stage or set visible again, Flash has to decompress them.

 

Are there any settings I might be able to set with LoaderMax to make sure it keeps a hold of the uncompressed bitmapData once it's ready?

 

From what I've seen when looking into this, it seems I didn't have the problem before because I used bitmapData.draw() somewhere along the line, since calls to bitmapData's methods seem to lock the bitmapData at that resolution. Similar workarounds I've seen say to do a simple bitmapData.getPixel32(0,0) just to do something to keep Flash from letting go of the decompressed version of the bitmapData. Unfortunately at this point, adding in a getPixel call of any sort makes the application do a silent crash. I've also seen that crossdomain issues can cause this, but we're loading images from a local subfolder of our project.

[GreenSock]

It sounds like you may be just asking too much of Flash. Loading all that bitmap data and having Flash decode it all into memory is just skyrocketing your memory usage, causing things to crash (from what I gather). I bet the reason Flash is dropping the decoded stuff from memory at times is because it's trying to stay alive and manage memory. Your question sounds like you're trying to figure out a way to prevent Flash from doing that (drop some of the decoded stuff at times), and there's no room to give so it's just crashing. 

 

From what I gather, it's not LoaderMax related at all - it's more of a memory thing. I don't see an easy solution here. I wish I had better news for you

[Ideum]

Yeah. We are trying to squeeze every last ounce of speed and detail that we can out of this application, hence switching to LoaderMax for our loading processes. It is a problem just with what we want to do and the limitations of Flash itself, at this point. Thanks for all the help with LoaderMax! I'll be off to figure this out.