tlaukkanen / mobile-trail-explorer

Automatically exported from code.google.com/p/mobile-trail-explorer
2 stars 0 forks source link

enh: improved memory handling #169

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Mobile phones typically have strict limits on memory (And in my opinion it
would be great if mte will continue to work on old devices)

The current uncontrolled use of Vector for trace log will sooner or later
make MTE die a painful death as memory runs out. (partly remedied by using
streaming-gpx though).

My suggestion is to replace the Vector trackPoints with some type of fixed
size ring buffer. This can be allocated in a controlled fashion to x
(defined by user) points, and further, the user can select to 'replace
oldest' or stop tracing when the buffer is full.  Even a status "trace
capacity nn % full" can be provided.

One should be careful to not allocate all remaining heap to this trace log
as other (dynamic) parts of the program will then fail.

Another point is the use of Images in various paint functions. If one could
get those from a factory (ie. not created every time) both speed and memory
management should be improved. 
The possible disadvantage is that inactive views will hold to memory it
doesn't need at the moment, with the worst case being the buffer Image in
TrailCanvas (i believe). If TrialCanvas is deemed a 'main view' of the
application that may be acceptable though.
-On the other hand the 'red dot' is only loaded and created once, and used
for every paint in every view it appears.

Combining the two, the ring buffer can be allocated last and use as much
memory as (safely) possible - and the user is only presented with the
(remaining) trace capacity.

This way the application will crash at startup and not in the middle of a
four hour trace. Not starting is a better better option than loosing data.

Being a C developer, I'm not certain all this is possible in java ME - or
worth the effort. It might pay off to look into though.

-- T

A ring buffer should (internally) keep an ReplaceAtIdx instead of Append();
removeAt(0); 

related issues: 
Issue #60
Issue #86 (partly)
Issue #151

future OutOfMemory issues :)

Original issue reported on code.google.com by ttyri...@gmail.com on 11 Mar 2009 at 9:54