Jump to content
GreenSock

Ideum

BusinessGreen
  • Posts

    4
  • Joined

  • Last visited

Reputation

1 Newbie

About Ideum

  1. 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.
  2. 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.
  3. 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!
  4. 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"
×