I am trying to use cached heap for camera preview using pgprot_cached() in vm_pg_prot for mapping a memory allocated by ion_system_heap(alloc_pages) to userspace. With this, I am getting a noise in camera preview. However, If I use pgprot_writecombine() or pgprot_noncached(), preview is proper. I tried flush_cache_all(), dma_sync_sg_for_device(), dma_sync_sg_for_cpu() for cache flush/invalidate before dumping the preview image to panel.
Is there anything else I need to take care?
Could this not be a cache coherency issue?
Related
I am having some memory issues with our android app when handling bitmaps (duh!).
We are having multiple activities loading images from a server, this could be a background image for the activity.
This background image could be the same for multiple activities, and right now each activity is loading its own background image.
This means if the flow is ac1->ac2->ac3->ac4 the same image will be loaded 4 times and using 4x memory.
How do I optimize imagehandling for this scenario? Do I create an image cache where the image is stored and then each activity ask the cache first for images. If this is the case, how do I know when to garbage collect the image from the cache?
Any suggestions, link to good tutorials or similar is highly appreciated.
Regards
EDIT:
When downloading images for the device the exact sizes is used, meaning that if the ui element needs an 100x100 pixel image it gets that size and therefore no need for scaling. So i am not sure about downscaling the image when loading it into the memory. Maybe it is needed to unload images in the activity when moving on the the next and then reload when going back.
One thing you might want to try is scaling down your bitmaps (make a thumbnail) to a size that is more appropriate to your device. It's pretty easy to quickly use up all the RAM on an Android device with a bitmap if you don't scale it down. This recipe shows how to do so on the fly. You could adapt this to save the images to disk.
You could also create your own implementation of the LRUCache to cache the images for your app.
After ready your update I will give you an other tip then.
I can still post the patch too if people want that..
What you need to do with those bitmaps is call them with a using block. That way Android will unload the bitmap as soon as that block is executed.
Example:
using(Bitmap usedBitmap = new Bitmap()){
//Do stuff with the Bitmap here
//You can call usedBitmap.Dispose() but it's not really needed
}
With this code your app shouldn't keep all the used bitmaps in memory.
There are a lot of answers for this question. But all of them are incorrect!
For example if I have created a CCLayer object with one CCSprite object. I have 3 textures and I want to switch between them on every touch.
For example I will use something similar to this:
link
I run this application in Simulator. Then I call a memory warning. Then I try to switch between images (textures). And I see that 2 of 3 images are deleted (except of the image was shown at the same time memory warning appeared).
I tried to use retain/release commands for CCSprite and ССTexture2D but they cause a situation when dealloc method of released object is never called.
So how to store them correctly? I want to store them at memory warning and release/remove them when the current layer is destroyed.
Store them in one texture atlas, created with Texture Packer. Then it's as simple as calling [Sprite setDisplayFrame:frameName] to switch the displayed texture.
By default on memory warning cocos2d will remove unused textures. The whole point of memory warning is that OS tells your app "hey, that's not okay, cut down your memory appetite or I'll shut you down", and your app should be like "oops, sorry, freeing memory now".
If you receive a memory warning when preloading textures, cocos2d's default behavior of removing unused textures will shoot you in the foot. More about this issue here.
My advice: remove the call to purge cocos2d's caches in the memory warning method in AppDelegate. Of course you want to be extra careful with your memory usage. Alternatively you could simply disable the behavior while you're preloading images, but this might simply move the problem to a later point.
I have a listbox in which I load images dynamically from the web as user scrolls. Consider it an infinite scroll. My current display size is 72X72. But if I increase the display size to 288x288 (4 times) after few minutes of scrolling the app exits giving a outofmemory system error. It has started to occur very often on my 512MB device for large images. This concerns me because it will occur more quickly for 256 MB devices. How to handle such situation as try catch do not handle these system errors? What is the most optimum way of handling such a huge list of images?
I have also gone through this damm issue of WP7 or WP7.5.
There is a huge issue with Images in Windows phone 7.
A image of appox size 900kb when read from Isolated storage as stream and set as a source of Bitmap class object than u will see there is huge change/rise in memory usage (in my case 5-6MB).
Just go through this website and u will understand the rest.
Silverlight-s-big-image-problem-and-what-you-can-do-about-it
For long image listing issue
1. Scale down the images u get from the server.
2. Use LongListSelector tool to list images using data virtualization technique
You can use Jeff Wilcox MemoryDiagnosticHelper to control the memory usage. If it's about 90 mb, you can run image clean up process.
Just unload BitMaps (Image.Source = null) for images wich user can't see at the moment.
And also it's good practice to compress images (use the server side compression for example).
I'm developing an app for WP7 (VS2010 Express for Windows Phone RTM and WP Emulator), but now im facing a big problem related to memory usage.
The app itself has like 12 views, and some of them are reused with different data. It's a newsreader, so the views are mostly listboxes (image thumbnail, stackpanels and textblocks).
The first view has a listbox with 30 items. This takes about 20MB of RAM, but as i navigate between views the current and peak RAM usage start to rise. Well the peak usage it's around 55MB which i think is OK, but the app has a gallery section in which after selecting a thumbnail it navigates to another view which displays a downloaded image (JPEG, 1131px × 1647px, ~486KB) but initially fit to the screen. Until here all good, but for scaling purposes i'm using Laurent Bugnion's Multitouch Behavior and the problem is that when i zoom in the image, the memory usage gets near 90MB (like 87MB last time i tested with the maximum scale size at 2.5).
Also after i navigate the views the current ram usage may permantly reach and stay at 35MB, which i beleive is due to the device caching some things.
So, as the title says, how can i avoid such huge ram usage?
Edit----
Also i'd like to ask if the fact that in my app one can navigate from any view to almost every other and that in between there's always a page transition animation (like the one for the phone list application template in the beta tools), may be contributing to the excessive memory usage.
Generally speaking you want to keep images as small as feasible (in dimensions and color depth, not necessarily file size). In order to display an image, the device must decompress it to an actual Bitmap, so in this case you're looking at a 1131x1647pixel image, let's say at 16bpp, means that you have a 3.7MB memory footprint for the image, not the 486k file size.
Depending on your zoom/rotate, there may be a second copy buffer, so you can effectively double that. It doesn't take long at that rate to get to 90MB. I'd certainly try either download smaller image files or try resizing them locally and then using the resized image.
Well maybe i should look into deepzoom (but when i first read about it, i thought it was for using it with the same image at different sizes, like google maps in satellite view), but yesterday i solved it by using a webbrowser inside my view, so if before i had:
<Image x:Name="imgPlaceHolder" delay:LowProfileImageLoader.UriSource="{Binding Path=ActualImageSource}" MaxHeight="800"
MaxWidth="480" >
<interac:Interaction.Behaviors >
<tbeh:MultiTouchBehavior x:Name="ImageMTB" IsScaleEnabled="True"
MinimumScale="0.4"
MaximumScale="2.5"
IsRotateEnabled="False"
IsDebugModeActive="False"
IsTranslateXEnabled="True"
IsTranslateYEnabled="True"
>
</tbeh:MultiTouchBehavior>
</interac:Interaction.Behaviors>
</Image>
I changed that to:
<phone:WebBrowser Source="{Binding Path=ActualImageSource}" x:Name="wbbigimage" />
It uses less memory and takes care of the zoom with no problems.
I'll wait a bit for someone with a better solution before checking this one.
A couple of things to note. First, make sure that you are clearing out any lists or images that you are using on pages durring the onNavigatedFrom method. The way WP7 Deals with images is "interesting". One of the things I have found to help is to null out the background of any panorama controls when the page is not being displayed.
As for your specific issue, have you considered using a MultiScaleImage (Deep Zoom) to cut down on memory?
http://msdn.microsoft.com/en-us/library/system.windows.controls.multiscaleimage(VS.95).aspx
Interesting problem here - I'm making a small game using Flex 3 - now I have a static ImageAccess class, which first loads up all images and stores them in a static array for quicker access in the future.
Now since I address the physical bitmapdata without calling Clone() (for efficiency issues) and once by accident I've written directly onto the bitmapdata.
Now the weird part - Flex uses some kind of weird caching and stores the bitmap with the new changes made to it - no matter what I do (restart Flex Builder, delete my cache, restart browser) the bitmap data is still loaded with the extra info (even though the image is without all that data).
Please help :D
Can you give more details about what extra info you're talking about?
Correct me if I'm wrong but Flex doesn't cache anything as such, the browser does, in any case , viewing with another browser should display the original image. If it doesn't , you may consider the possibility of some forgotten function still acting on the original bitmap... have you tried viewing the application in another browser by the way?
there's also the possibility of the original image being corrupted for whatever reason...