Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 3 days, 3 hrs ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 3 days, 4 hrs ago -
Maemo repository (3)
to Community by torsen - 3 days, 19 hrs ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 4 days, 17 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 6 days ago - more...
 |
gnuite |
2008-01-16
, 03:02
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#161
|
Originally Posted by cool-n800
Heading is also indicated by the blue line coming out of the dot that indicates your location. If it's not big enough for your tastes, considering increasing the Draw Width in the Settings dialog.
|
|
2008-01-16
, 03:04
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#162
|
Originally Posted by cool-n800
Enable "Auto-Rotate" by either pressing the down button on the D-pad (in the default configuration) or by using the "View | Rotate | Auto-Rotate" menu item.
When I drive with N800 + Mapper + GPS, I want to see a map moving towards my the direction in which I am going. i.e. the blue dot should always move upwards.
Is it possible ?
I have tried auto center options -- lead and lat/lon but it just keeps the dot in center. The map moves anywhere but not upwards (or downwards, I should say).
Any clue ?
 |
|
2008-01-16
, 03:13
|
|
Posts: 150 |
Thanked: 6 times |
Joined on May 2007
|
#163
|
Originally Posted by gnuite
also when Tracking is turned on it gives you an idea where you have been and where you are heading. which i love
Heading is also indicated by the blue line coming out of the dot that indicates your location. If it's not big enough for your tastes, considering increasing the Draw Width in the Settings dialog.
__________________
the highest risk in life is life, it has 100% chance of causing death
the highest risk in life is life, it has 100% chance of causing death
|
|
2008-01-16
, 03:15
|
|
Posts: 81 |
Thanked: 115 times |
Joined on Jan 2008
|
#164
|
Is there some way to defrag or optimize the maps .db files? MM2 used to work very quickly when I first started using it, but now I downloaded many maps and the .db file is 900mb and displaying of maps is much slower now, especially when changing zoom levels.
Last edited by iKneaDough; 2008-01-16 at 03:20.
Last edited by iKneaDough; 2008-01-16 at 03:20.
|
|
2008-01-16
, 03:17
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#165
|
Originally Posted by nutter
In my testing, GDBM was clearly slower than using the file system directly (as it was done in versions prior to v2.0). But file system overhead inflated disk requirements by (in some cases) up to an order of magnitude. It's a tradeoff that MANY people asked for.
MM2 uses gdbm database to save the card space and make the interface simple, the drawback is that gdbm is not that efficient. Every time you fetch a key or data, it allocates memory twice - read from the file and make a copy then give it to you, user has to free the memory - this approach is not necessary in this application. I delete that in my windows gdbm library, since MS runtime simply refuses to free the memory and crashes. Redundant memory allocation of gdbm is a slow factor.
I also tested sqlite3 as an alternative. Although slower than using the file system directory hierarchy, GDBM was much faster (and a little bit smaller) than sqlite3.
Originally Posted by nutter
At best, I could make it 9 bytes, but that doesn't line the memory up very well, and ARM is much more efficient with 32-bit ints that are aligned along 32-bit boundaries. Besides, hash values are calculated at most once per map access (or maybe 12 times per screen draw). That's not a lot of CPU utilization.
Hash value calculation is quite consuming in gdbm, which depends on the key length. The MM2 uses 12 byte key, it seems too long, there is no difficult to condense it to 8 byte length, it can save some time.
Originally Posted by nutter
This was implemented in Maemo Mapper v2.3. Give it a try, and see if it satisfies your speed requirements.
The most important, there is basically no cache management in gdbm, every time you fetch a key or data, it goes into reading file. It really slow you down. So implementing cache management is definitely a good way to smooth things up.
Originally Posted by nutter
That's actually quite close to how it's implemented, except that the thread division is as such:
From my point of view, it may be improved if we have a SW architecture like
GUI <--> cache management <--> downloading/file read/save
1. One thread for the GUI (the Main Event thread). This is standard in all GTK+ applications.
2. One thread for rendering the screen (done in the background and includes cache access and file system access for maps that are already downloaded).
3. Up to four threads for downloaded maps in the background.
The best way to speed up the app is to avoid the three doing intensive jobs all together at the same time, so when GUI is busy the SW doesn't do saving, when downloading GUI should be told to wait, the central piece should be the cache manager.
Last edited by gnuite; 2008-01-16 at 03:20.
| The Following User Says Thank You to gnuite For This Useful Post: | ||
|
|
2008-01-16
, 03:25
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#166
|
Originally Posted by iKneaDough
Actually, there is a function in the GDBM API to re-organize the files, but I don't provide the functionality in Maemo Mapper itself. I'll add a button in the "Manage Repositories" dialog to allow users to "reorganize" the file. It's also the only way that the database file can get smaller. (Space used by deleted maps is marked and reused when needed later.)
Is there some way to defrag or optimize the maps .db files? MM2 used to work very quickly when I first started using it, but now I downloaded many maps and the .db file is 900mb and displaying of maps is much slower now, especially when changing zoom levels.
Depending on the size of the database, this operation might take a while....
|
|
2008-01-16
, 03:42
|
|
Posts: 81 |
Thanked: 115 times |
Joined on Jan 2008
|
#167
|
Originally Posted by gnuite
My database size is over 900mb so I sort of expect it to take a long while.
Depending on the size of the database, this operation might take a while....
I was thinking of copying the file to my pc and optimizing it there. What packages would I need installed, and what command should I use?
I do notice a speed improvement in 2.3 over 2.2, however 2.3 does seem to crash more and harder.
Also, would it be possible to Auto-download only in some repositories and not others? Maybe put the Auto-download option on the "Manage Repositories" dialog as well, if it won't clutter it too much.
Thank you, gnuite for all the time and effort that you put into this great program, and for helping it's users!
Last edited by iKneaDough; 2008-01-16 at 03:45.
|
|
2008-01-16
, 03:47
|
|
Posts: 26 |
Thanked: 2 times |
Joined on Nov 2007
|
#168
|
i am using n800 with os2007 and while MM worked fine most of the time, it sometimes refuses to start after previously exiting from the application. when this happen i need to restart my tablet to get it working again.
i decided to use turn on cpu monitor on one occassion when MM wont start. it says MM was already running and taking up 36% of system ram. i killed the process and sure enough MM was able normally after that. MM seems to have exited improperly the last time taking up valuable system resource.
just wondering if anyone here encountered this.
i decided to use turn on cpu monitor on one occassion when MM wont start. it says MM was already running and taking up 36% of system ram. i killed the process and sure enough MM was able normally after that. MM seems to have exited improperly the last time taking up valuable system resource.
just wondering if anyone here encountered this.
|
|
2008-01-16
, 04:01
|
|
Posts: 33 |
Thanked: 16 times |
Joined on Dec 2007
|
#169
|
gnuite, thanks for clarification.
I am really not a linux/unix guy, in real life I am doing the real-time sw to make a living, plus windows as the side dish. Our company doesn't allow to deploy linux since the dispute with SCO(?) scares them, so they drew that policy 2 years ago.
I think your guys may give dbd, qdbm or tokyo cabinet some try, to see which is the fast dbm system. I will put the source code of my modified wingdbm soon, which removes the double memory allocation, and puts all gdbm functions into one file. So it's very easy to port that to other platform in static link, you can try that as well to see any performance gain.
MM is really a great toy which is very cool. As user, we're very please to see you guys make any progress.
I am really not a linux/unix guy, in real life I am doing the real-time sw to make a living, plus windows as the side dish. Our company doesn't allow to deploy linux since the dispute with SCO(?) scares them, so they drew that policy 2 years ago.
I think your guys may give dbd, qdbm or tokyo cabinet some try, to see which is the fast dbm system. I will put the source code of my modified wingdbm soon, which removes the double memory allocation, and puts all gdbm functions into one file. So it's very easy to port that to other platform in static link, you can try that as well to see any performance gain.
MM is really a great toy which is very cool. As user, we're very please to see you guys make any progress.
|
|
2008-01-16
, 04:07
|
|
Posts: 33 |
Thanked: 16 times |
Joined on Dec 2007
|
#170
|
Originally Posted by iKneaDough
If you never delete any map tile in db, then there is no gap, just the nature of gdbm, which becomes slower when the db grows too big.
Is there some way to defrag or optimize the maps .db files? MM2 used to work very quickly when I first started using it, but now I downloaded many maps and the .db file is 900mb and displaying of maps is much slower now, especially when changing zoom levels.
If you used to delete the maps within it. Then you need to re-organize it since deleting doesn't shrink the gdbm file size actually, just leave a unused gap within the file.