I am writing a Cocoa program for Mac, and it includes a picture viewer.
What the picture viewer's job is to download a picture from web and show it. It would do this every time I click a button who would give it a picture URL. So this would be frequent.
My design goal is, every time after I change to another picture or close it temporarily (it is not the main window), it will release the memory it takes. For example, before I open the picture viewer for a picture, my application takes 1M memory. After I open a picture, it takes about, say, 2M memory. And after I close it, it will decrease the memory usage to the original 1M.
The problem is, sometimes after I viewed a picture, especially a big one, the viewer won't give all the memory it took, for example, opening it cost about 20M memory, but after I close it, just 10 of the 20 released, the another 10 is still there and never be freed. It looks like memory leak, but I checked my code and analyzed it many times, I couldn't find any memory leak, and also, some other pictures won't behave like this.
this is weird, is this possibly certain Cocoa internal memory cache policy? Any suggestions would be appreciated. Thanks in advance!
Update: Today after I added a scrollView as a wrapper of the imageView, this weird memory problem seems almost fixed.
Thanks for your advice, edc1591, I will continue to figure out what happened.
Without seeing the code it's hard to tell quite what the problem is. But until I see the code, I'll give you a few pointers for dealing with this:
Enable Garbage Collection. If you already have it enabled, try forcing a garbage collection after releasing the image file like this:
[[NSGarbageCollector defaultCollector] collectIfNeeded];
Try heapshot analysis. Here's a good tutorial on that.
I'll update this answer once the code has been posted.
Related
Okay the Title can be misleading.
But it´s like this.
I have made an application that constantly sends Images from Client A to Client B.
When Client B receives the image, it will replace the last image.
I currently use Picturebox or Panel, so pretty much:
panel1.BackgroundImage = Image.FromStream((MemoryStream)NetSerializer.Serializer.Deserialize(tt1.GetStream()));
It looks weird though, but as you can se, it will just change the image, when it´s there.
This all goes well up to about 800x600, then it will bottleneck.
I don´t know the update frequency, but i am guessing it´s around 60fps, as i am taking screenshots from my desktop or particular windows.
The bandwidth is not the problem here as long as i don´t use .bmp at 800x600+ of course.
Anyway, my question is, what can i use to replace this way of showing images?
I am guessing something with Directx/OpenGL or something?
Sadly i haven´t found a way to even display an image with that, though then again, i have a hard time understanding it.
I am open for suggestions and examples.
EDIT:
I am thinking, maybe to use WPF to just show the image.
But i don´t know if i can change the background image from a winform, so if it´s possible then i am all ear.
Thanks
I got an exceedingly strange problem. I have a SidebarDocumentsIcon.icns file (the same one used by finder) that I load into an NSImageWell. However, at certain critical sizes(width between 17-18 pixels) my image becomes completely scrambled in both the interface builder and the compiled app. This only happens to certain images for some reason, and never used to happen before. I tried to restore my repository, made sure that every byte is in the right place, but still this annoying bug keeps on happening. Has anybody here experienced this problem before? Any tips on solving it?
I'm trying to do some animations using Java3D on a Mac.
If I use universe = new SimpleUniverse(); to create a universe, everything is fast. The problem is that there's a bit of tearing sometimes because I'm altering object properties while in the middle of rendering. What I would like to do is stop the rendering while I'm updating properties.
My first step was to try creating my own Canvas3D, and that's where things went wrong. Rather than just creating a SimpleUniverse, I do this sort of thing:
GraphicsConfiguration config = SimpleUniverse.getPreferredConfiguration();
canvas = new Canvas3D(config);
universe = SimpleUniverse(canvas);
When I do this, the first problem is that the window doesn't automatically appear. So based on the example at java2s, I embedded the Canvas3D in an applet. Then I get a window, but performance is TERRIBLE. The rendering is MUCH slower.
It's almost as though the rendering is no longer being done by the graphics engine but instead in software.
Can anyone give me some tips as to what I'm doing wrong here?
Thanks!
You should try compiling your BranchGroups before they become live. This helps preprocess the objects before they get displayed in the universe. It might also be something else that java is getting hung up on, if you put the whole source in the question, then i could tell you more. It might also just be your computer, Java3D takes a big hunk of Memory and is pretty CPU intensive, your computer specs would also be relevant in answering this question
Hope that helped you out a little bit, if you add more to your question i would be happy to help you more
I'm currently trying to track down a GDI handle leak. I am currently using GDIView to track it down. The tool divides the GDI objects into categories Pen, ExtPen, Bitmap, Font, Palette, Region, DC, Metafile DC, Enhanced Metafile DC, and Other GDI. These categories are summed in a column called GDI Total. Ontop of that, there's a column called All GDI. It is in this column I am detecting the leak.
As I don't have the source code for the tool, I can't see what's really going on. Did the author of the tool miss a handle type? It looks like it. I do know there is a leak, because some users report that they are shown the infamous dialog A required resource was (end of text). It may take weeks for the dialog to show up, so I'm pretty sure it isn't a DC.
Any ideas on how to track this down would be much appreciated! As I have a limited budget, thousand dollar tools are out of the question. Debugging hooks into GDI would suffice, as I don't mind doing detective work.
I found the problem. Apparently, GDIView thinks that icons fall under the unknown category. The problem was an icon being loaded and attached to an object. The object was not setup to auto delete the icon upon destruction. E-mailing the author of said tool...
Once I had a similar problem and I used Task Manager - asked it to show GDI handles count for each process and stepped over the program code to see where the handles count unexpectedly increases and fails to decrease back. It took some time, but finally using divide-and-conquer I found the error.
In my app, I am loading several images onto a UIScrollView and I highlight a portion of the scroll view using Core Graphics routine. I have used the CGImageRelease and CGContextRelease to manage the memory during the routines.
When I run the app using instruments (allocation), I see that the memory consumption keeps rising with every swipe of the scrollView. This at one point leads to the app becoming really slow.
For loading different images, I use the UIImage ImageNamed method, I have come across some posts indicating that this is not a good idea since the method results in autoreleased images which creates memory issues. I would like to know if I am looking a the right place for the error. What could be the possible place to look for this unusual memory consumption?
Also, using the allocation of Instruments, I can just see that increase in the memory, is it possible to pin point the code where these allocations happen?
Thanks in advance for your help!
Best
DKV
For loading different images, I use the UIImage ImageNamed method, I have come across some posts indicating that this is not a good idea since the method results in autoreleased images which creates memory issues.
No, that's not the issue. Anything that doesn't involve you calling alloc, init[WithSomethingOrOther:], and release yourself is going to get the image autoreleased.
The problem is that imageNamed: continues to own the image after it hands it to you. Every image you obtain from imageNamed: stays in that cache, permanently associated with that name. It's not merely a “load this image” method; it's a “load this image and keep it alive forever*” method.
*Where “forever” means “until the end of my process”.
I would like to know if I am looking a the right place for the error. What could be the possible place to look for this unusual memory consumption?
In Instruments. It will tell you exactly how many of each kind of object you are creating, and how much total memory objects of each kind are occupying, and you can sort that list to determine what's eating up memory. Then you can drill down into each class and into each object to determine what's keeping objects alive after you need them.