As I discovered in the previous articles, loaded bitmaps are stored in memory in two forms: the compressed PNG, JPEG, JPEG-XR, GIF file and the uncompressed RGBA pixels. If you don’t use the pixels, Flash Player will reclaim its memory and then uncompress it if you use the bitmap later on. However, if you do plan to use the bitmap, isn’t the compressed file data just memory overhead? Today’s article will show you how to dump this unused file data and save a bunch of memory.
Posts Tagged memory
I’ve mentioned the concept of VRAM (video memory) in a few articles, but I still find constant confusion among readers of this site as well as coworkers and colleagues in day-to-day work with Stage3D. Today’s article will hopefully clear up the differences, dispel some myths, and help you make the best use of both of them.
Flash 11’s new Stage3D enables us to make amazing 3D games and applications in Flash. It also burdens us with two forms of memory: the system memory (RAM) we’re used to and the video card’s memory (VRAM) that stores objects like textures, buffers, and shaders. In order to not use more VRAM than the player’s video card has, we must know how much VRAM they have. Unfortunately, the Stage3D API does not provide us with this information. Today’s article provides a workaround function that allows you to quickly test your players’ VRAM. UPDATED to fix some bugs in the test
The Dictionary class provides perhaps the most useful support for weak references—and therefore garbage collection control—in the AS3 Flash API. However, due to a subtle error in its documentation, you may inadvertently be leaking a lot of memory. Today’s article shows you how this can happen and how you can easily fix the leak.
During some recent memory profiling I was reacquainted with just how many ways there are to unknowingly allocate an object in AS3. The problem is seldom the allocation itself, but rather the later garbage collection (GC) to delete those objects. Ever used a Flash profiler only to see a huge chunk of your CPU time going to [reap], [mark], or [sweep]? Yeah, that’s the GC at work. Today’s article talks about some of the ways you end up allocating objects in AS3 without using the new keyword. These subtle errors can end up costing you!
I was reminded about the flash.sampler API by Grant Skinner’s recent post about it. While only available in the debug player, it can still tell us some valuable information about what goes on in the release player. Today I’m using the getSize function to find out how much memory overhead various classes impose, even when they are empty.
Weak key support in the Dictionary class is one of those rarely-used features that can be greatly useful on occasion. This is the only place in the Flash API where weak references are used. In Java, there is another useful class for when you just want to make one weak reference, not a whole table of them: the aptly-named WeakReference class. Below is my own implementation, which is both simple and useful.
The garbage collector (GC) in Flash Player 9 and 10 is a notorious source of performance problems. This is caught in the Flex Builder profiler as [mark] and [reap] steps as the GC marks objects to free and then actually frees them. Additionally, the actual allocation of new objects is slow. Today’s question asks “can we improve performance by managing some of our own memory?” This article shows one way to take a little control of memory management. (SPOILER: this technique can yield a 2100% speedup!)