Bílý vrch
icon TrekBuddy
www.trekbuddy.net
Outdoor companion.
  • internal / bluetooth / simulator GPS
  • offline raster maps
  • smart GPX / raw NMEA logs
  • waypoints and simple navigation
  • custom views
  • MIDP and Symbian phones
  • Blackberry
  • Android
Visit wiki to see all features, guides and howtos. Project tracker.

Partners:    (Polish/Polski)(Polski) Compass mapy      (Polish/Polski)(Polski) Galileos mapy      (Polish/Polski)(Polski) CartoMedia      (Czech/Èesky)(Èesky) Eaglesoft trasy      (Polish/Polski)(Polski) ExpressMap     

 FAQFAQ   SearchSearch   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
0.9.72
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   This topic is locked: you cannot edit posts or make replies.    TrekBuddy Forum Index -> Recycle Bin
View previous topic :: View next topic  
Author Message
Peter Atanasov



Joined: 13 Sep 2007
Posts: 25
Location: Bulgaria

PostPosted: Fri Jan 18, 2008 7:44 pm    Post subject: Reply with quote

Hi Kruch
the new version with .tmi support work realy fast but there is a problem on my k750i, when I switch levels in atlas for example from Road to Street and back Java exception error appears?? The old version 0.9.67 work perfect.

_________________
k750i -> 5800XM -> N8
Back to top
View user's profile Send private message
kruch
Site Admin


Joined: 02 Jul 2006
Posts: 5664

PostPosted: Fri Jan 18, 2008 7:47 pm    Post subject: Reply with quote

With 0.9.72? What exception exactly?
Back to top
View user's profile Send private message
MaleSMurf



Joined: 10 Sep 2007
Posts: 120

PostPosted: Fri Jan 18, 2008 10:49 pm    Post subject: Reply with quote

Just tried this version on my 6300...

Memory at start 1.2MB, after loading a map 690KB, after a few seconds moving the map crashes and memory shows 49KB Shocked
Back to top
View user's profile Send private message
guest



Joined: 08 Oct 2006
Posts: 4989

PostPosted: Sat Jan 19, 2008 1:30 pm    Post subject: TB is faster than that I've experienced with other system... Reply with quote

TB is faster than that I've experienced with other system. But I meet an error in open "Load Map" in TB (v0.9.72), it says "java.lang.SecurityException: Application not authorized to access the restricted API". However, I am loving it a little. The cell phone I am using is Motorola A1200. I hope I can experience it further.
A suggestion is enhancing its function of touch screen, for A1200 has no keyboard.
Back to top
View user's profile Send private message Visit poster's website
filipo



Joined: 23 Aug 2007
Posts: 40

PostPosted: Sat Jan 19, 2008 1:58 pm    Post subject: Reply with quote

kruch wrote:
kruch wrote:
Could you take all PNGs from TrekBuddy (/resources/*.png), include them in the jar as resources and then in your midlet try


Please also include /resources/set/world_0_0.png, it is the biggest one...


Here are the promised results:

Using the native image load:

Total/Free/Used memory: 2097152 / 1483324 / 613808

Using the custom image load:

Total/Free/Used memory: 2097152 / 1483324 / 613828

It means that both native and custom image load work with almost the same efficiency (the native load is a little bit more efficient, not a big difference though).

Now some theory - is 600k too much or is it ok?

I investigated all the images, there sizes and bits per pixel. I noticed that if there is less than 8 BPP (4 BPP in our case), then the memory used by the image is exactly height X width, and for higher color resolution (32 BPP) the memory used by the image is height X width X 4.

Then I summarized all the images I have loaded into following table:
Code:

Image          Width    Height    BPP        Optimal                 Real
                                         Uncompressed Size    Runtime Uncompressed Size
=======================================================================================
arrows          510        51      32        104040                 104040
bullets          40        10      32          1600                   1600
crosshairs      243        81      32         78732                  78732
icon             15        15      32           900                    900
icon.store.mem   16        16      32          1024                   1024
icon.store.mema  16        16      32          1024                   1024
icon.store.xml   16        16      32          1024                   1024
icon.store.xmla  16        16      32          1024                   1024
naviws          650        65      32        169000                 169000
pois             63        21      32          5292                   5292
wpt              21        21      32          1764                   1764
set/world_0_0   320       320       4         51200                 102400 *)
set/world_320_0 320       320       4         51200                 102400 *)
=======================================================================================
TOTAL                                        467824                 570224

*) For 4BPP images the memory usage is not optimal


According to the table above, the used memory should be something like nearly 600kB, which is corresponding with the real test - the difference between actual image size and real used memory is 613808 - 570224 = 43584 bytes, which could be everything else but the images.

I also tested your development shapshot - it is a little bit better but not much - it saves about 100k of memory, but the OutOfMemoryError is still thrown when scrolling over a few tiles.

Conclusion? The initial images do not take that much. With all the images loaded there is another 1.4M memory available. It should be fairly enough for loading the map slices.

Can we go on? Any idea? I am ready to run other tests.
Back to top
View user's profile Send private message
filipo



Joined: 23 Aug 2007
Posts: 40

PostPosted: Sat Jan 19, 2008 2:22 pm    Post subject: Reply with quote

filipo wrote:


Using the native image load:

Total/Free/Used memory: 2097152 / 1483324 / 613808



One more interesting report:

When I do not call System.gc() before I create the report, the result is as follows:

Total/Free/Used memory: 2097152 / 1112700 / 984452

It is evident that now there is much more memory wasted. Does trekbuddy call System.gc() often enough and in appropriate places?
Back to top
View user's profile Send private message
flyfinder



Joined: 19 Jan 2008
Posts: 1

PostPosted: Sat Jan 19, 2008 3:38 pm    Post subject: TB may be th best for DIY. Can it work in MOTO A1200? Reply with quote

TB may be th best for DIY. Can it work well in MOTO A1200?
Back to top
View user's profile Send private message
zen-scotsman



Joined: 31 Dec 2007
Posts: 10

PostPosted: Sat Jan 19, 2008 4:15 pm    Post subject: Nokia 5200 - BlueNEXT BN909GR Reply with quote

Just got my hands on a bluetooth GPS, and it works great with the latest version on my Nokia 5200 with only one problem, I can't get it to write tracklogs to memory card, apart from this it's just about perfect Smile
Back to top
View user's profile Send private message
kruch
Site Admin


Joined: 02 Jul 2006
Posts: 5664

PostPosted: Sat Jan 19, 2008 6:30 pm    Post subject: Reply with quote

filipo, thanks a lot, excellent work! It is a nice surprise that 8bpp (and less) images are kept as byte-per-pixel by the runtime - I did not expect that at all...

The price for "nice" UI (32bpp semitransparent arrows etc) appears quite high: ~350 kB of heap memory on Nokia. That is not good. Maybe all built-in images could be dithered into 8bpp (some even to 4bpp) without making them uglier.

Anyway, here is the important thing: Google maps are 8bpp. So I checked maps produced by gm2tb - tiles are 32bpp pngs. I also checked MaleSmurf's map - tiles are 24bpp. It is useless on itself, and in the context of your finding, we can say that it is has very negative impact on _runtime_ memory consumption, at least on some Nokia devices.

Another important thing for map-makers: if tiles are smaller than screen size (in both dimensions), then during map browsing, you can have up to 9 tiles loaded and decoded at one moment. Example: tiles 200x200 with 240x320 screen of recent devices.

map takes 9 * 200 * 200 * 4 = 1440000 bytes (~1400 kB)
built-in images take ~350 kB

There is not much of 2 MB heap left for code itself Sad

...

TB calls System.gc() on itself at several code spots, for others (and one of them is before a tile is loaded or after it is released) there is an option Settings->Misc->forcedGc that has to be checked. I added one more conditional System.gc() today. But it has been intended to workaround some memory leak on older S60 devices, and should be left unchecked, unless .... it helps Very Happy

...

Another option that may affect memory consumption on buggy midp implementations is Settings->Misc->safe renderer. I however did not noticed effect on N6230i, K750i, and on some devicesit just has to be checked (IBM J9, Blackerry, Siemens I think too), so it is checked by default and unchecking it usually does help anything Wink
Back to top
View user's profile Send private message
MaleSMurf



Joined: 10 Sep 2007
Posts: 120

PostPosted: Sun Jan 20, 2008 12:11 pm    Post subject: Reply with quote

I just loaded the maps from gm2tb again, and now they are saved with 8bpp and not 24bpp like before.

Now, memory shows after loading the map and scrolling in all directions 1,16MB space an there is NO crashing Very Happy
Back to top
View user's profile Send private message
kruch
Site Admin


Joined: 02 Jul 2006
Posts: 5664

PostPosted: Sun Jan 20, 2008 4:36 pm    Post subject: Re: TB is faster than that I've experienced with other syste Reply with quote

guest wrote:
But I meet an error in open "Load Map" in TB (v0.9.72), it says "java.lang.SecurityException: Application not authorized to access the restricted API".


You may need to go through a crazy process like this one - this is howto for MGMaps: http://forum.mgmaps.com/viewtopic.php?p=3501#3501

guest wrote:
A suggestion is enhancing its function of touch screen, for A1200 has no keyboard.


What exactly do you suggest?
Back to top
View user's profile Send private message
kruch
Site Admin


Joined: 02 Jul 2006
Posts: 5664

PostPosted: Sun Jan 20, 2008 4:37 pm    Post subject: Re: Nokia 5200 - BlueNEXT BN909GR Reply with quote

zen-scotsman wrote:
Just got my hands on a bluetooth GPS, and it works great with the latest version on my Nokia 5200 with only one problem, I can't get it to write tracklogs to memory card, apart from this it's just about perfect Smile


Did you create tracks-nmea and tracks-gpx folders?
Back to top
View user's profile Send private message
kruch
Site Admin


Joined: 02 Jul 2006
Posts: 5664

PostPosted: Sun Jan 20, 2008 4:39 pm    Post subject: Reply with quote

FYI, I have made 0.9.73 available with new ShowAll feature; if anyone is interested in testing Wink , here's the topic:

http://www.trekbuddy.net.forum/viewtopic.php?t=941
Back to top
View user's profile Send private message
filipo



Joined: 23 Aug 2007
Posts: 40

PostPosted: Sun Jan 20, 2008 4:57 pm    Post subject: Reply with quote

kruch wrote:
The price for "nice" UI (32bpp semitransparent arrows etc) appears quite high: ~350 kB of heap memory on Nokia. That is not good. Maybe all built-in images could be dithered into 8bpp (some even to 4bpp) without making them uglier.


I agree - I will appreciate a little uglier arrows etc. if the application does not fail Very Happy

I checked one of my altases. The slices are 384x512, 4BPP. It means that each slice takes 196608 bytes on my phones. As they are bigger than the display, up to 4 slices can be loaded at once. However, 4 slices need 786432 bytes of memory. Even if I suppose that the initial world map is unloaded, the memory left on my phone is not enough. That explains quite clearly why it sometimes works and sometimes not - the memory is enough for going through the middles of the slices (when max. 2 slices are loaded at once), but not near the edges of the slices (when up to 4 slices can be loaded).

What can people like me do avoid the OutOfMemoryError?

One solution is to make the slices smaller. But you have to be careful not to make the slices only slighlty smaller than the display to avoid what kruch has described in his recent post (loading up to nine large slices).

It seems to be a good idea to create slices of the same size as your display is (if it is not too large). In my case, the size of the display is 240x320. Such slices are not huge, and up to 4 can be loaded at once. Let's count: Max. amount of memory used by the slices is 240x320x4=307200 bytes. That is ok since I have more than 0.5M free memory after fresh start (including two world map slices which will be released as soon as I load an atlas).

Problem: Too much work to reslice my atlases Sad
Good news: I wrote a java application which does the work for you Smile

Using the application it is easy to experiment with the slice sizes. I converted my atlases to the slice size of 240x320 and everything is now perfect! No OutOfMemoryErrors any more Smile

As everything else, this conversion also has drawbacks. Most of them are caused by the fact that my application is not good enough though (see below).

How to use it?

1) Download the attached application
2) Download apache commons-compress (only if you do not have one in your classpath) from http://repo1.maven.org/maven2/commons-compress/commons-compress/20050911/commons-compress-20050911.jar
3) Place both jar-s into the same directory (to make it simple)
4) Run java -cp mapoptimizer.jar:commons-compress-20050911.jar fh.soft.trekbuddy.tools.MapOptimizer <source atlas folder> <target atlas folder> <new slice width> <new slice height>

If everything goes well, you should find the refactored atlas in the target folder.

Note: If you are on Windows, use "-cp mapoptimizer.jar;commons-compress-20050911.jar" instead (replace ":" with ";")

Known issues:
- only tarred atlases are supported
- only lower case extensions (such as .tar, .map, .set, .png) can be used in all atlas files
- poor option parsing (may fail or throw NullPointerExceptions)
- poor memory usage optimization (if it fails on heap space, add -Xmx1M option to the command line - if you have enough memory on your computer of course)
- only PNG based atlases are supported
- all PNGs are converted into 256 color indexed images
- if the source images are 16 color, then the total size of the atlas is approx. three times larger than the original
- if the source images are 256 color, the total size is increased too, but not so much (java plugins for PNG are not as good as GIMP)
- and maybe more... (the application is about 10 hours old)

The application is open source. You are welcome to add/fix something. If you find it useful, it would be good to check in the application into some public CVS or SVN repository.

Some more ideas to implement:
- adding .tmi index (not sure if the .tmi suffix is correct) files to atlases (to speed up map loading)
- remapping colors in images (e.g., shrink all images to 16 colors)
- preserving true color if the original is true color (for satellite maps)
- support for untarred atlases and single maps
- converting a single map into an atlas
- gui

BUT
I have found a workaround for devices like Nokia 6234. But where is the memory really gone? It would still be worth investigating!



mapoptimizer.jar
 Description:
Map Optimizer binaries

Download
 Filename:  mapoptimizer.jar
 Filesize:  12.55 KB
 Downloaded:  177 Time(s)


Trekbuddy Tools.zip
 Description:
Map Optimizer source

Download
 Filename:  Trekbuddy Tools.zip
 Filesize:  85.9 KB
 Downloaded:  418 Time(s)

Back to top
View user's profile Send private message
start78



Joined: 17 Oct 2007
Posts: 186

PostPosted: Mon Jan 21, 2008 10:56 am    Post subject: Reply with quote

MaleSMurf wrote:
I just loaded the maps from gm2tb again, and now they are saved with 8bpp and not 24bpp like before.

Now, memory shows after loading the map and scrolling in all directions 1,16MB space an there is NO crashing Very Happy


Gm2tb has already been improved to save images with 8bpp since end of october 07...

_________________
Nokia 5800XM (FW 21.0.025 T-Mobile Ger) / TB 0.9.89 / Atlas by TBAC
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   This topic is locked: you cannot edit posts or make replies.    TrekBuddy Forum Index -> Recycle Bin All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group