Because I'm developing on mobile devices, I wanna to remove no longer used objects (sprites) from memory. Should be detachChild be enough to have it out of memory ?
What about the src references. How to remove/detach them from the dom ?
Related
I'm writing a client for a multiplayer tile-based game in libGDX (for Android and Desktop).
The game world is composed of thousands of small 32x32 png images that are drawn into a large rectangular view area. The images are downloaded over the socket connection (network) as needed.
What is the best (fastest and most resource-efficient) way to store these images in "memory" so they can be drawn really fast onto the screen when needed?
So far, I have implemented a very naive algorithm that will load each and every 32x32 image into a Texture and keep that in memory indefinitly. (Pure coincidence my images got a size that is a power of two.) It seems to work, but I am worried that this is very inefficient and possible exceeds GPU resources on older devices or something.
I am aware of the TextureAtlas, but that seems to work only for static images that are packed and stored in the compiled android app. As I receive my images over the network dynamically, I believe this won't work for me.
I have found this libgdx SpriteBatch render to texture post that suggest rendering many small images into a FrameBuffer, then using this as a source of TextureRegions. This seems promising to me. Is this a good solution?
Is there a better way?
I also wonder if drawing and storing my small images into a large Pixmap might be helpful. Is this possibly a better approach than drawing into a FrameBuffer, as described above?
As I understand it from the docs, Pixmaps are purely memory-based. That might be an advantage as it probably doesn't need graphics resources, on the other hand might be slower as loading into a Texture is an expensive operation. Thoughts on this?
Actually TextureAtlas is the best way to store many images (small or not) and fortunatelly the TextureAtlas instance do not have to be created in a static way.
Take a look at
addRegion(java.lang.String name, Texture texture, int x, int y, int width, int height)
TextureAtlas'es method. It make it possible to create atlas dynamically.
So what you should do is to create empty atlas
TextureAtlas atlas = new TextureAtlas();
then add your images in some kind of loop
for(Texture texture : yourTexturesCollection)
atlas.addRegion(...);
then you can use your atlas by using findRegion or another method (take a look at reference)
Notice that for android devices it is recommended to use not larger atlas than 2048 x 2048px.
For another kind of devices (like dekstop) this value can be another (usually bigger). It is not LibGDX limit but openGL's!
My sprites are 4KB (png)- black squares and I probably creating about 200 of them throughout the game plus 2 small textfields each- should I worried about getting garbage collection right? 277 jpg Kb image resides permanently(full basic colour) and about 30 Kb gifs of images. No moveiclips.
It really depends how much animation you're doing with these objects. at the same time, garbage collecting can cause rendering to pause momentarily... If you're seeing this issue, then consider using memory saving techniques such as object pooling to keep garbage collection to a minimum.
Otherwise, let the garbage collector do what it's designed for, and leave it.
Thumb of rule will be remove all pointers from object (event listeners and child objects) and remove it from parent.
To be more specific read this - http://www.skinkers.com/2010/10/08/memory-management-in-air-as3-flash-garbage-collection/
monitor your memory over time with a simple tool as : http://www.emanueleferonato.com/2011/09/01/moviemonitor-an-as3-performance-monitor-with-10-1-features/ if you discover issues you can find for more complex profiling tools.
You usually don't want to force garbage collection but follow these common rules and let flash player do the rest
I"m developing a diagramming application in HTML5/JavaScript. All drawing is done with SVG, using Raphael or qooxdoo SVG (not settled yet). The drawing area should use custom background image. The image is too big to be downloaded (several megabytes for 2560x1600 Retina resolution), that's why I construct it on the fly, composing it from tiles and applying bitmap effects. For that, I use HTML5 canvas. After that, the resulting background image has to be made accessible from SVG. To achieve that, I export a data URI from the canvas, and use <image xlink:href="data:image/png;base64,..."/> inside SVG.
This works for simple examples, but I'm a bit concerned about memory usage in production. Given that the image takes 12MB in memory (2560 * 1600 *3 bytes ber pixel), how much additional memory will be used? I suppose that at least some megabytes will be allocated to store base64-encoded PNG-compressed representation as data URI, and another 12 megabytes will go to the buffer for the SVG <image> element.
I wonder if there is a method to short-circuit this and to avoid redundant image encoding-decoding?
You can go around the base64 part with canvas.toBlob(callback) and window.URL.createObjectURL(). Other than that I don't think there is a place for you to further limit memory usage.
https://developer.mozilla.org/en-US/docs/Web/API/window.URL.createObjectURL
The toBlob() method can be shimmed on some browsers: https://github.com/blueimp/JavaScript-Canvas-to-Blob
I have a slideshow type portion of an AIR Mobile for iOS I am working on. There are four pages that the user can scroll through. Each page contains a PNG (as large as 1MB, even after compression) loaded in using the Bitmap class and two TextFields. As I am scrolling through them (using a custom scroll framework that works without any issues throughout the app), the app is caching each of the PNG images as a Bitmap as they come onto the screen and unloading them when they leave the screen after a period (most likely the next GC, though it seems to be less random than GC).
The act of caching the PNGs is incredibly slow on iOS, especially when it is happening while another action (such as scrolling) is happening. This produces a ~1 sec delay while scrolling, which is obviously unacceptable. Is there a way to either a) prevent the caching or b) keep them cached longer/indefinitely until the images themselves are eligible for GC?
I've triple checked my code and nothing is set to cacheAsBitmap. Additionally, I've been using Adobe Scout to pinpoint what was causing that momentary freeze and it is definitely from caching the images. I've also eliminated any transforms or scales or filters or anything that might turn cacheAsBitmap on in order to operate and the results remain the same.
It turns out that bitmap caching wasn't really the problem afterall. After much more examination, I found that it was actually PNG decompression. Basically, Flash was decompressing PNGs as they were coming on screen (which is even more expensive than caching), adding those to memory, and undoing the process after they had been off the screen for a period of time, meaning I would have to decompress all over again after that period of time for each image.
To get around this, you simply need to access the BitmapData object in some way. I used getPixel( 0, 0 ) in my constructors and the images were decompressed and loaded into BitmapData permanently upon doing so. It will add a bit of time to the startup, but preloading in this fashion results in better performance.
To avoid this decompressing on the run (on demand) you can instead request flash to decompress it on load. This will increase the load time but improve the perceived performance of the app since a separate thread takes care of the decompressing. This of course means no jitter or skip when the image hits the screen.
var loaderContext:LoaderContext = new LoaderContext();
loaderContext.imageDecodingPolicy = ImageDecodingPolicy.ON_LOAD
var loader:Loader = new Loader();
loader.load(new URLRequest("http://www.adobe.com/myimage.png"), loaderContext);
See: http://help.adobe.com/en_US/as3/dev/WS52621785137562065a8e668112d98c8c4df-8000.html
And
http://www.bytearray.org/?p=2931
Embedded images (via code) are not supposed to be compressed, so this problem shouldn't occur with applications that do so. However, if you are like me, and you use the Flash Pro IDE to import PNGs or other bitmap assets, Flash Pro compresses them as JPG by default, using the setting provided by the image itself.
To fix this and avoid these decompression issues, simply go to your Flash Pro asset library, right click on the image you want to change, click on properties and select "lossless / PNG/GIF" as compression. This will increase largely the load time but you will have the much better perceived performance discussed here. This should be done in addition to implementing the code above, or it will make no difference.
In my experience the frame rate average dropped only by one frame per second, but it's much more consistent without any skips or lags which is essential for games.
Since Flash Player will free the decompressed bitmap memory of a BitmapData, here's a solution if decompression still occurs after this: Keeping Bitmaps Decompressed.
I'm developing a little desktop app using Adobe Air and their HTML API.
The app has two window, one displaying a slideshow of images present in a folder on the local machine and the other window allows you to browse those images (one big image and prev/next buttons).
At first for a quick test I just loaded all images from the folder into the DOM of each window and it works just fine until I reach too many images (150+) as they are high resolution JPEGs from a DSLR. Obviously each image is taking a lot of memory and will probably kill the app from overleaking. So I started with optimising the browsing window, instead of loading them all I use just a single tag and replace the .src value with javascript. But this technique is just delaying issues because as I carry on browsing all images the memory usage is growing and growing. Replacing the src of the image does not release the memory used by the previous image. Same thing if I try to delete the image from the DOM and recreate it.
An idea I have but I don't like it too much is to display the image inside a frame loading another HTML file passing it the image src as parameter. Then reload the whole frame, hopefully it can reset the memory usage. Haven't tried yet.
Anyone has an idea of how to handle this?
This is a nice tool for optimizing your Adobe Air application. Adobe Air Tuner:
I'm not familiar with your project; or how it is being implemented. The Adobe AIR has several methods that are accessible to free memory. Which will allow you correctly remove or dispose of your objects. Those cleanups can be found here.
One thing that some people do when creating media players; especially ones with large media. Example:
Lets say your media player contains six pages of content; totaling 1GB of total data. That is a very, very large memory allocation for your project. So rather then call the entire 1GB at once; the first page loads and the second page loads.
The other four pages remain 'uncalled' not dynamically loading. Then the user switches to page two; page three the content begins preloading. The user switches to page three; page four will start to load. But it also disposes of the array or objects created in page one. This way it doesn't affect the application.
Obviously this way is tedious, as your controlling all aspects of the loading. Also it poses issues if your user starts moving to quickly through the pages.
So another possible solution; would be to create thumbnails so the size is drastically smaller. Then load full size images as stand alone streams that can be disposed of without any issues once they leave that area. That way the gallery is stand alone from that.
If you provide some code or some additional details I can possibly assist you above and beyond just interface / memory suggestions of implementation.