Oh No, is this a HUGE Flash 8 memory leak?

[ghoyer]

If you drag a large zoomed movieclip with many vectors (like a map background) Flash 8 will gobble up memory like mad (how about 200MB per minute with constant dragging). Using the new Flash 8 scrollRect technique has the same leaky effect. This problem did not occur in Flash player 7. I have reported this as a bug to MM. I was hoping Flash 8's new bitmap caching techniques would actually improve performance when dragging large zoomed maps around but just the opposite has occured. I really really need this to be fixed.

My suspicion is that the problem has something to do with the new garbage collection mechanism and/or some kind of behind the scenes attempt at automatic bitmap caching but whatever the cause, the result is a memory leak that does not go away until flash 8 crashes (standalone or plugin). It is easy to reproduce and does not happen on flash player 7 (stand-alone or plugin).

The memory leak occurs when dragging a large movie clip (2400x2800) with many vectors, like in a street map background. When the movie clip is at 100% (_xscale = 100) you can drag the clip (using startDrag and stopDrag) all day long with no change in memory consumption (as viewed in Task Manager).

However, if you zoom in on the movie clip to say 600% (_xscale = 600) and then drag you'll see your memory consumption jump every few seconds while you are dragging. Interestingly, just dragging the mouse back and forth over the same area without releasing the mouse will cause flash 8 to continue to allocate memory until you stop dragging. The fact that any amount of zoom causes the clip to exceed the magic 2880x2880 bitmap threshold makes me suspect flash is trying to convert part of the vector to a bitmap and cache it behind the scenes. Also, the more zoomed in you are the faster the memory gets consumed. More concerning is that the memory never seems to get freed up. Even unloading or even removing the movie clip does not free up the memory.

As a point of reference, in the flash 7 player no additional memory was consumed by dragging the same movie clip regardless of the zoom or _xscale.

I have been impressed that Flash has thus far proved to be a great platform for building large map based GIS apps so I hope this is just a bug that can be quickly resolved or I'm in serious trouble. Dragging a zoomed street map around is a very common task in GIS based apps but with the Flash 8 player the user will only be able to do this for a few minutes before they run out of memory and completely lose responsiveness and ultimately crash the player.

Since I can't attach a .swf file that shows the problem I'm pointing to another Flash site that has my example.

http://www.kirupa.com/forum/attachme...chmentid=29930

Is anyone else seeing the same memory consumption that I am? Can anyone from MM confirm this is not the intended behavior? Thanks.

[FlashGuru]

In the Flash 8 Player, there is a limit on the size of bitmaps stored in memory. If any object with bitmap caching turned on is larger than 2880 in either direction (width or height) then bitmap caching is automatically turned off. This would explain why the dragging works fine at 100 xscale/yscale, but when you zoom in, the player re-draws the bitmap which is then too large (bigger than 2880) and thus bitmap caching is turned off.

My suggestion = cut up the map into smaller pieces.

This is not a bug, it is a problem with the way you have implemented the feature.

[ghoyer]

Thanks for your input FlashGuru but I have to disagree with your analysis. First, to clarify, I am NOT using the bitmap caching feature. The test example is just a clip with lots of vectors so when you zoom it Flash 8 should just be recalculating the vectors like it does in Flash 7 and redraw them. No bitmap conversion or caching should be taking place. The fact that gobs of memory are being consumed when dragging tells me that Flash is trying to do something behind the scenes, maybe it's trying to cache on its own, but whatever their attempt at optimzation is it is clearly failing from a memory use standpoint. If Flash was just recalculating the vectors like it should be then why the increasing memory consumption that never gets freed up?

I understand that vector clips will not be converted to bitmaps and cached if they exceed 2880 in either dimension but again I am not using this feature.

Breaking up the map may be a workaround but it would be a workaround for a bug and it's not going to be easy to implement. I have attached the source of the test for more details. Note the frame rate for my movie is 30fps.

My latest observation on this problem reveals memory consumption of approximately 2MB per 5 pixel mouse drag when zoomed to 700 over a "Nowhere Street" piece of text. That's a lot my any measure and just shouldn't be happening.

[FlashGuru]

Ouch, your right, i get the same results. Ill see what i can find out. Im sure there is a reason for the increase in memory usage, but not quite so sure why the memory isnt freed.

[ghoyer]

Thanks for your help. I hope you can get someone at MM to look at this because I think it's really serious. I'm in a mad rush to get this problem noticed as It basically kills my app.

You may also want to note that I have tried several workarounds including using the new scrollRect feature instead of startDrag/stopDrag with the exact same memory consumption problem so it is not specific to old drag functions. I have also tried using both unloadMovie and removeMovieClip then either attaching a new vector clip from the library or loading a new vector clip from a web server to try and get the memory freed up all to no avail. It's a real bugger this one.

Do let us know the scoop when you find something out.

[emolen]

this might offer some advice
http://www.gskinner.com/blog/archiv..._flash_pla.html
let me know what you think. I have a similar problem where my app encounters a fatal error do to a memory leak, no one has helped me fix it yet and I'm totally stumped, but the link above will shed some light and offer some work arounds.

[ghoyer]

emolen,

I also just discovered this Blog thread and posted a response. It is evident from that thread that there is a problem with the overall GC scheme. Their example demonstrates the problem when using the BitmapData API. My example occurs when using the built-in movieClip.startDrag / movieClip.stopDrag methods on a large zoomed vector clip.

FlashGuru, did you find anything out yet? The blog that emolen refers to had a response from a guy named Tommy who appears to work for MM. He made it sound like the GC issue raised in the blog was not serious enough to warrant a dot release but should be added to the "to do" list for 8.5.

I'm hoping that my example adds to the evidence that there are several ways to break the GC mechanism in Flash 8 and the sooner a fix is available the better.

[emolen]

Touché

[McUsher]

The problem seems to be even worse...
I downloaded the "Memory Leak Test 4.zip"
removed all AS and Controls

I let only the "mcMap" on stage/libary and put
the following lines in first frame:

code:

---

_root.onEnterFrame=function  () {

	mcMap._xscale=_xmouse;

	mcMap._yscale=_ymouse;

}

---

The FF memory usage kept growing ... (i stopped at a quarter gig)

I then reduced mcMap to very few Vectors and only a tenth of the size
it got in your Demo and _x/yscaled it by factor 10*_x/ymouse.
Same memory leaks occured.

I would bet, that _any_ vector sized more than these magic 2400x2800px
which is either being rotated/scaled will cause this leak to show up.

Sorry for my bad Krautenglish just hope u got the point.

[ghoyer]

Finally, someone from Macromedia has acknowledged this as a known bug. Hopefully, if it's not a major design flaw, we'll see a fix in 8.5.

http://www.macromedia.com/cfusion/we...&enterthread=y

[ghoyer]

Fellow developers, I have comfirmed that this memory leak has been FIXED in the new 8.5 alpha release 8.5.0.212

Thanks to the Adobe/Macromedia engineers for nailing this one. Zooming and dragging large complicated vector clips does not increase memory at all now. Also, the performance and CPU usage does not seem to be affected by zooming. Dragging a large complicated vector like a map works as well at 150x as at 1x.

Now, can we please get the Flash IDE updated to the new player ASAP. The IDE's player appears built in and it makes testing a real pain because of the version 8 memory leak.

The new 8.5 alpha browser plugin is available here:

http://www.macromedia.com/cfusion/en...RC00184&e=labs

Note: to get the stand-alone version you'll have to install the full Flex 2 Builder beta.

[dasso]

And when it's supposed to be free?

[peter_u]

I've been beating my head over this.

I have some scale-action going on in my movie. It resizes some movieClip (all vector with imported text in it) up to 200 percent. And whenever the MC was scaled up, the CPU Usage maxed out.

Even when the movieClip is scaled to 100 percent the CPU Usage is close to maxing out - and there the MC is only about 960 x 560 pix.

Anyway, I downloaded the player 8.5 and all works totally smooth...
Actually, as it seems here, the Firefox-Plug-in works better than the ActiveX-IE-plug-in - but that just might be me...

Standalone Versions are available:
http://www.macromedia.com/cfusion/en...flashplayer8_5

[stephank]

Same here. Tried to find worarounds since December. Now with the alpha 8.5 player things work well. This is really frustrating. Any news on when the 8.5 will be officially available?

[stephank]

Same here. Tried to find worarounds since December. we're also doing a large scale map that can be dragged around. Now with the alpha 8.5 player things work well. This is really frustrating. Any news on when the 8.5 will be officially available?