Is flash smart enough to "hide" PIXELS that aren't on the stage, in order to decrease memory usage? Or I must do it manually, if it decreases the memory usage at all?
Flash does not render objects that aren't on the stage (as per http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e3e.html).
However I think you may be mixing up two different issues.
One issue is CPU/GPU performance - for this there is no need to worry about off-stage objects as Flash does not waste time rendering display objects that are outside the stage bounds.
The other issue is memory usage. Every object that you create takes up some memory whether or not it is visible on the screen. Flash has a garbage collector that will periodically dispose of unused objects, however "unused objects" means an object that isn't referenced by any other object so if you are having memory issues you will have to manually clean up objects by removing event listeners, nulling references etc.
There's nothing like that available to decrease memory usage. If it's visible on your monitor, it needs to be rendered by Flash and have a place in memory storing the pixel colour.
Although Flash is very fast these days, especially with hardware acceleration. So you shouldn't worry too much about performance, there's a lot of bang for your virtual buck with AS3. I'd bet all of my virtual dollars on it.
Flash will store all bitmaps, movieclips in fact all objects in memory as expected. If you have a large bitmap which is larger than the stage, it still occupies memory regardless of you only showing a portion of it.
If you have multiple bitmaps or movieclips that may move off the stage and no part of them are visible, then the only way to recover memory is to make sure the object is dereferenced and set to null.
myMovieClip = null;
Prior to setting to null you would also have to make sure that nothing else is referencing the object, for example it can't be stored in an array or have any event listeners attached to it so therefore:
myMovieClip.removeEventListener(Event.WHATEVER, eventHandler);
For bitmapdata objects you would need to call dispose first before setting to null:
myBitmapdata.dispose();
myBitmapdata = null;
This then allows the GC to recover memory when it chooses, unless you are using AIR which means you may request a gc call yourself:
System.gc();
If you are developing in Flash Builder, the best practice is to regularly profile your application and hit the button to force a gc call. You can then see which objects are persisting in memory and locate the references which are causing the memory leaks.
Related
I am making racing game in Libgdx.My game apk size is 9.92 mb and I am using four texture packer of total size is 9.92 Mb. My game is running on desktop but its run on android device very slow. What is reason behind it?
There are few loopholes which we neglect while programming.
Desktop processors are way more powerful so the game may run smoothly on Desktop but may slow on mobile Device.
Here are some key notes which you should follow for optimum game flow:
No I/O operations in render method.
Avoid creating Objects in Render Method.
Objects must be reused (for instance if your game have 1000 platforms but on current screen you can display only 3, than instead of making 1000 objects make 5 or 6 and reuse them). You can use Pool class provided by LibGdx for object pooling.
Try to load only those assets which are necessary to show on current screen.
Try to check your logcat if the Garbage collector is called. If so than try to use finalize method of object class to find which class object are collected as garbage and try to improve on it.
Good luck.
I've got some additional tips for improving performance:
Try to minimize texture bindings (or generally bindings when you're making a 3D game for example) in you render loop. Use texture atlases and try to use one texture after binding as often as possible, before binding another texture unit.
Don't display things that are not in the frustum/viewport. Calculate first if the drawn object can even be seen by the active camera or not. If it's not seen, just don't load it onto your GPU when rendering!
Don't use spritebatch.begin() or spritebatch.end() too often in the render loop, because every time you begin/end it, it's flushed and loaded onto the GPU for rendering its stuff.
Do NOT load assets while rendering, except you're doing it once in another thread.
The latest versions of libgdx also provide a GLProfiler where you can measure how many draw calls, texture bindings, vertices, etc. you have per frame. I'd strongly recommend this since there always can be situations where you would not expect an overhead of memory/computational usage.
Use libgdx Poolable (interface) objects and Pool for pooling objects and minimizing the time for object creation, since the creation of objects might cause tiny but noticable stutterings in your game-render loop
By the way, without any additional information, no one's going to give you a good or precise answer. If you think it's not worth it to write enough text or information for your question, why should it be worth it to answer it?
To really understand why your game is running slow you need to profile your application.
There are free tools avaiable for this.
On Desktop you can use VisualVM.
On Android you can use Android Monitor.
With profiling you will find excatly which methods are taking up the most time.
A likely cause of slowdowns is texture binding. Do you switch between different pages of packed textures often? Try to draw everything from one page before switching to another page.
The answer is likely a little more that just "Computer fast; phone slow". Rather, it's important to note that your computer Java VM is likely Oracles very nicely optimized JVM while your phone's Java VM is likely Dalvik, which, to say nothing else of its performance, does not have the same optimizations for object creation and management.
As others have said, libGDX provides a Pool class for just this reason. Take a look here: https://github.com/libgdx/libgdx/wiki/Memory-management
One very important thing in LibGDX is that you should make sure that sometimes loading assets from the memory cannot go in the render() method. Make sure that you are loading the assets in the right times and they are not coming in the render method.
Another very important thing is that try to calculate your math and make it independent of the render in the sense that your next frame should not wait for calculations to happen...!
These are the major 2 things i encountered when I was making the Snake game Tutorial.
Thanks,
Abhijeet.
One thing I have found, is that drawing is laggy. This means that if you are drawing offscreen items, then it uses a lot of useless resources. If you just check if they are onscreen before drawing, then your performance improves by a lot surprisingly.
Points to ponder (From personal experience)
DO NOT keep calling a function,in render method, that updates something like time,score on HUD (Make these updates only when required eg when score increases ONLY then update score etc)
Make calls IF specific (Make updations on certain condition, not all the time)
eg. Calling/updating in render method at 60FPS - means you update time 60 times a sec when it just needs to be updated once per sec )
These points will effect hugely on performance (thumbs up)
You need to check the your Image size of the game.If your image size are more than decrease the size of images by using the following link "http://tinypng.org/".
It will be help you.
Tried finding some info on this without success.
When instantiating a movieclip for later use. Is it using a lot of performance before actually adding it to stage? The question is when is flash working more. At adding to stage or instantiating to mmemory?
It depends on what is in it and what it is doing. If everything in it is graphic, it should only use CPU if it is on the Display list. If it has ActionScript code, it will depend on what that code is doing. For example, listening for ENTER_FRAME will use significant CPU cycles, as will instantiating new objects. Note that having objects coming and going from the timeline also instantiates objects.
If the object contains a lot of data (for example a BitmapData that is a 1000 x 1000 uncompressed jpg), then it will use a lot of memory.
I am working on a graphic design, vector drawing application that needs to render the data in every frame when there is a change. The issue is, that if the user is moving nodes, there will be changes during every single frame. This is not an issue with a tiny amount of data and is a major slowdown when there is anything more than a minor amount of data.
The reason is that in order to render I preform calculations and store data inside arrays. Then when the function responsible for the computation is done, the GC simply discards the data and next time the function is called, we create new arrays and new data.
In C++ I would probably allocate space in the memory and write to that space(over and over). I would probably improve performance that way. In languages that us GC I cannot allocate space that way. I have to do an ugly hack where I define an array as a class member and then write to that array from the function over and over although that array is only used in that one function and is not used by other methods of the class.
My questions is, what is the best way to reuse memory space in a language that uses GC?
Object pooling would be the major one, see here:
Gotoandplay Tutorial
Also
10 Top Tips around GC
I would also suggest you read through Grant's explanation of the garbage collection system in the Flash Player, it's quite unique, and understanding how Flash handles data is quite important to data intensive scripts.
This presentation
I've been working on a library, and have run into a problem with application memory.
I created a class called FileManager which allows the user to call a function called loadNewFiles - this function opens a multi-file selection dialog and stores each FileReferenceList in a vector. I can call the removeList function at any time and remove that list and clear any memory and listeners allocated to that list, so all's well there.
I created another class called UploadManager, which takes an array of FileReference objects and uploads them to a URL via the uploadFiles function. The memory leak appears to be here. When you call this function, it adds the appropriate event listeners and calls the upload function. If the upload fails or the upload is finished, it removes the listeners and clears the vector it has been waiting in.
after the upload manager finishes uploading the files, I call the removeFiles function in FileManager (which, remember, worked perfectly before) and... Nothing happens. The files are removed from both vectors, the listeners are removed from both files, but the memory stays allocated. This obviously has potential to cause problems along the road, as there's no limit to the number of files, uploads, etc. available through the library.
classes:
FileManager
UploadManager
Implementation
It sounds like from your example that the UploadManager still has a reference to the files either from the vector passed into uploadFiles, or some other object in the game still has a reference.
Also note, System.gc() only works on the debug version of the flash player.
So you can't depend on it for an architectural design choice. It works for unit testing memory intensive operations when you need to see the consumption of ActionScript memory "on demand".
In a production product, the ActionScript Virtual Machine is very active in detecting when and where to garbage collect. Most would say it happens right when you don't want it to.
Try profiling the application and looking at the "cumulative instances" vs. "instances", as well as the "cumulative memory" vs. "memory" for the objects in question (i.e. FileReference).
You can force garbage collection during runtime in the Profile View to get a realistic idea of how much memory is actually freed when garbage collection takes place in the Release version.
I'm building an Adobe AIR desktop app with Flash CS5 that makes a lot of use of bitmapdata, bytearrays and base64 strings. After a while the memory usage of the app doubles.
Is it recommended to use system.gc() to free memory at that point or is that bad practice?
Thanks.
system.gc is a debug only functionality in AIR and Flash player. I think the better thing is to recycle bitmapdata and other objects if you can to avoid gc, and if not call bitmapdata.dispose() and bitmapdata = null as soon as you are done with using them.
If you have bitmap objects of the same size at various times in your project, you can use the same instance of BitmapData to operate on them. This is similar to how ItemRenderers recycle items or how even other platforms like iOS's UITableViewController recycles/reuses UITableViewCell. Garbage collection is not panacea, it should be used when easy programmability is more important than performance.
You don't need to call system.gc as it will be called automatically on idle cycles by the Flash runtime. If you call it yourself you might end up slowing down your application for no real gain.
When you don't need a BitmapData or a ByteArray anymore, just call BitmapData.dispose() or ByteArray.clear().