Hi Paul, Can you please tell us which version of Java you are using to run AOI? This information is available in the "Help | About" menu. Could you also please tell us how you installed AOI? The 2 possible causes of your error that I can think of are: the permissions on the Plugins folder somehow blocks reading by the user that is running AOI; the version of Java you are running is causing the code that "finds" the AOI home folder to fail. Obviously there are other possibilities, but let's start...
Firstly - great work! Thank You! Secondly, I would need to refresh my memory on this, but I believe that in addition to any links that may be put on the website - the AOI Help system, which is generally language sensitive, could load and present the French version of the manual to a French user. As I said, I need to refresh my memory on that - it has been a long time since I prepared any new text for the Help system. Kind Regards, Nik
but ,when that happens after calling .gc() the process typically took some 200 - 900 ms, which seems a very long time to me The Java GC process has various types - GC of "Eden", which is intended to be as fast as possible, with the downside that it doesn't examine all memory (which is what makes it so fast). Then there is GC of "Young" memory, which examines more memory and is consequently slower; and then there is GC of "Tenured", which examines all memory, and is slowest. (There may be more or...
Another tool for observing what's happening is to call Runtime.getRuntime().totalMemory() and Runtime.getRuntime().freeMemory(). These 3 calls are made by the Help option, and displayed in the "Help About ArtOfIllusion" panel. :)
Another tool for observing what's happening is to call Runtime.getRuntime().totalMemory() and Runtime.getRuntime().freeMemory(). These 3 calls are made by the Help option, and displayed in the "Help About ArtOfIllusion" panel. :)
Thanks for the responses. So the bottom line is: * The Java GC process does not ever release any memory to the OS - it simply releases unused objects back to the Java heap; There are settings for some - or possobly most - Java implementations which will cause the Java heap to shrink or grow, and shrinking would quite likely happen after successful GC; if there is a memory leak occurring, it could be happening within Java itself - causing objects not to be released back to the Java heap - or it could...
I don't think there is [a memory leak] What makes you think that? What measurements did you take to check for memory leaks? Just watched the Windows' TaskManager and, what it tells about each process. In which case you are not actually measuring the Java Garbage Collection. The Java GC reclaims the memory consumed by unused objects and returns that memory to the internal Java heap, for future reallocation. However, the Java heap grows and shrinks independently. So the memory consumed by the Java...
I would expect the plugin to be very visual: the point-editor plugin could live in the sidebar; whenever a point is selected, the point-editor plugin would display the coordinates, and allow them to be edited. if multiple points were selected, then the point-editor plugin would display those points - in a scrollable area - and allow any to be edited with a maximum of (say) 10 points - to avoid insane scrolling panes if a 1 milltion point mesh were selected... a simple "copy" button would copy all...