[Announce] modRana: a flexible GPS navigation system - Page 57 - maemo.org

Active Topics

The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 3 days, 6 hrs ago
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 4 days, 2 hrs ago
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 6 days, 11 hrs ago
more...

Page 57 of 207

Thread Tools

petur	2011-03-07 , 08:23
Posts: 650 \| Thanked: 497 times \| Joined on Oct 2008 @ Ghent, Belgium	#561

Since the last update I find modRana feels slower, sometimes doesn't respond to taps or takes several seconds to do so. Already rebooted, no help. Rest of the device / progranms still feel ok

Anybody else experienced this or is this specific to my setup :/

__________________
Affordable mobile internet in Belgium: Try Mobile Vikings
2 GB, 1000 SMS and 15 euro of talk time for.... 15 euro

Quote & Reply |

The Following User Says Thank You to petur For This Useful Post:
MartinK

nordicnurse	2011-03-09 , 18:46
Posts: 7 \| Thanked: 5 times \| Joined on Jan 2010	#562

Originally Posted by petur

Since the last update I find modRana feels slower, sometimes doesn't respond to taps or takes several seconds to do so. Already rebooted, no help. Rest of the device / progranms still feel ok

Anybody else experienced this or is this specific to my setup :/

I have noticed the same.

(also added an idea to autozooming ticket)

Last edited by nordicnurse; 2011-03-09 at 19:07.

Quote & Reply |

MartinK	2011-03-09 , 22:35
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#563

Originally Posted by skykooler

Question about that: might it be possible to parse the beginning of the plain-text command such as to extract things such as "turn left", "slight right", "merge", etc. and show an arrow indicating what the next command will be? I would find this very handy when I can't remember the last instruction, but I don't want to take my eyes off the road for long enough to read the blue box.

Well, I have been considering a turn type icon once I can get some turn type metadata from some routing provider, but good point - it also looks doable this way, using the directions provided by Google.

Originally Posted by skykooler

I believe you are using Python for modrana. Here is an example of what I mean:

Code:

def get_turn_direction(gmaps):
	#calling the google maps string "gmaps"
	gmaps_array = lower(gmaps).split(); #Convert to lowercase and split words
	if gmaps_array[1]=="left":
		if gmaps_array[0]=="turn":
			return "turn_left"
		elif gmaps_array[0]=="bear":
			return "bear_left"
		elif gmaps_array[0]=="exit":
			return "bear_left"
		else:
			return "turn_left"
	elif gmaps_array[1]=="right":
		if gmaps_array[0]=="turn":
			return "turn_right"
		elif gmaps_array[0]=="bear":
			return "bear_right"
		elif gmaps_array[0]=="exit":
			return "bear_right"
		else:
			return "turn_right"
	else:
		if gmaps_array[0]=="merge":
			return "merge"
		elif gmaps_array[2]=="left": #i.e. "Take first left"
			return "turn_left"
		elif gmaps_array[2]=="right":
			return "turn_right"
		elif gmaps_array[0]=="exit": #with no side specified, assume right exit
			return "bear_right"
		elif gmaps_array[0]=="continue":
			return "straight"
		else: #Catchall for other commands that I haven't anticipated
			return "don't_know"

Yeah, this should work - but I got an idea that scales better:

use a CSV file, just like abbreviation substitution list
the CSV contains trigger_word,icon_name pair, ordered by priority (once a trigger word is found in the message, rest is skipped)
use regexps to do the matching, probably match just the beginnings of the messages lowercase (as in your example)
there should be probably one file per language to keep things maintainable

Like this, support for more more languages can be added quite easily, without writing language specific code.
Also, the grammar used by Google seems looks quite simple after all: this is what a transcontinental route looks like

Originally Posted by skykooler

My suggestion is that this be used to display an arrow, sort of like this:

Well, I am thinking about where to put there arrow (when there is one)

The flexible UI layout that modRana has complicates this quite a bit

I think I'll implement per-mode position for the routing info box + place the "widget" wit the arrow somewhere where it does not collide with an UI element.

Originally Posted by petur

Since the last update I find modRana feels slower, sometimes doesn't respond to taps or takes several seconds to do so. Already rebooted, no help. Rest of the device / progranms still feel ok

Anybody else experienced this or is this specific to my setup :/

Originally Posted by nordicnurse

I have noticed the same.

(also added an idea to autozooming ticket)

It is quite possible there could be something wrong in the last version - the cause could be two-fold:
I could have broken something input related while adding support for long-clicks or when adding the new map dragging method. I have also noticed some exceptions while downloading a tile fails. I also have not yet done the sqlite related optimizations mentioned earlier.

If you can find some easily reproducible slowdown/UI unresponsiveness or send me logs of this happening, it would probably help me debugging this issue a lot

Originally Posted by nordicnurse

(also added an idea to autozooming ticket)

Thanks !

__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)

Quote & Reply |

The Following 3 Users Say Thank You to MartinK For This Useful Post:
nordicnurse, skykooler, wumpwoast

nordicnurse	2011-03-11 , 18:46
Posts: 7 \| Thanked: 5 times \| Joined on Jan 2010	#564

Originally Posted by MartinK

If you can find some easily reproducible slowdown/UI unresponsiveness or send me logs of this happening, it would probably help me debugging this issue a lot

Well, trying it out today its difficult to pinpoint any specific slowdown. The whole UI feels more sluggish than before (on overclocked N900).
However, these seem particularly slow to respond:
- Toggling fullscreen on/off
- After buttons disappear toggling them back again
- Map drawing seems a bit 'jerky' if zoomed in and with some speed (~80kmh); like draw, draw, draw, pause, draw. Didn't notice that before, but it definitely could be just me.

No lag is present when on menu screen.

I can log console output to file and press buttons if that helps you, but if you need more specific debug information I'd need some direction

Happy to help where I can

(edit: just to try, I disabled sqlite db and the lag went from bad to worse, about threefold )

Last edited by nordicnurse; 2011-03-11 at 19:57.

Quote & Reply |

The Following User Says Thank You to nordicnurse For This Useful Post:
MartinK

jj0	2011-03-11 , 19:23
Posts: 73 \| Thanked: 33 times \| Joined on Nov 2010	#565

Originally Posted by MartinK

It is quite possible there could be something wrong in the last version - the cause could be two-fold:
I could have broken something input related while adding support for long-clicks or when adding the new map dragging method. I have also noticed some exceptions while downloading a tile fails. I also have not yet done the sqlite related optimizations mentioned earlier.

If you can find some easily reproducible slowdown/UI unresponsiveness or send me logs of this happening, it would probably help me debugging this issue a lot

Well, I drove 1200 km today and am almost 100% confident there is a problem with displaying tiles, or there is some associated task that's happening when tiles are retrieved for display.

Basically, I have been reporting the issues of modrana slowing down since enabling the sqlite db, and I have wrongly attributed it to the sqlite. However, it's been getting progressively worse and worse, and currently modrana is almost unuseable for navigation while driving. I will explain shortly. The issue is not connected with the sqlite db, as even regular file tile saving option behaves the same.

Basically, I have confirmed today that when zoomed in and driving fast, meaning new tiles are constantly drawn from the top, in only a couple seconds the CPU load grows immensely - top shows modrana is hogging the CPU and mem, no other app running, and the phone fails to cope, no new tiles are drawn, and you're left with just a green field of "Loading" tiles.

It seems tiles are loaded for display sequentially, i.e. FIFO, even when the tile is no longer to be displayed, it seems the system is processing it and only then getting to further ones. Furthermore it seems to me, they are not released from memory.

You can easily replicate this behavior on an N900 by first zooming in to say 100m, then scroll rapidly left a couple of screens, after one or two moves, the phone doesn't manage, it's all green, even though the tiles are there.

If you then leave it for a minute or so, the system catches up and displays tiles.

So the only way to drive now after a while is zoomed all the way out, so that the tiles move VERY slow, even then when an edge of a new one appears on top, it takes like a minute for it to be displayed.

My thinking is, maybe the tile is reloaded for display even every miniscule move, so then if it moves more again, it moves a little again... Don't know, but obviously the system is not coping...

Plus the phone got super hot, as it was working overdrive and it was not coping.

This behavior has been getting progressively worse, since around the time I reported it the first time, around when the sqlite option was introduced.

I'm thinking, you must've changed the graphic loading and display of the tiles, Marting... Or introduced some working over of the tiles when loaded or something. But like this it's just very bad...

Please don't take this the negative way, modrana is great. However this issue has been getting worse and worse and it's now almost unuseable for navigating while driving at high speeds.

The only solution is always to close it. Then restart and it will load the tiles "fast" meaning like in two or three seconds for a while, which is however still not good, because when zoomed in and driving they move off the screen in two seconds, so it doesn't manage again.

I haven't looked at the code at all, but remember you mentioned changing the drawing code or something, I think its connected with that.

But on the N900 it's easy to reproduce, like I said just keep dragging then zoom in or out then drag, after a little while it gets stuck. However when you zoom back in or out to what was displayed it displays the tiles fast, meaning that they are probably in memory, then zoom out and it's just green for a minute...

Quote & Reply |

The Following User Says Thank You to jj0 For This Useful Post:
MartinK

skykooler	2011-03-12 , 03:59
Posts: 482 \| Thanked: 550 times \| Joined on Oct 2010	#566

I also have experienced a slowdown lately. Pressing buttons take about a second to respond. I wonder whether this is a processor or RAM issue? No overclocking here.

Quote & Reply |

MartinK	2011-03-13 , 02:33
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#567

I'm already working on solving this issue - I have changed the tile loading mechanism to first load the most recently requested added tiles (tiles currently on screen), I am also now discarding old request that were not handled on time - no need to load a tile you scrolled past while dragging the map half a minute ago that is no longer on screen.

Technically - I am now using a circular stack for handling tile loading requests

Results look good so far - definitely feels more responsive while doing fast scrolling and I'm planing some field testing soon (= inter-city bus ride

).

I've got further responsiveness improvements while a lot of tiles are being downloaded (eq. visiting a new area, zooming up in new area, etc.) from the network by setting a lower limit on the number of concurrent automatic tile download threads.

You can try this too - it is already possible to tweak in the current version. Just go to options->network->Network-usage and play with the Max. nr. of threads for tile auto-download option

Quote & Reply |

The Following 5 Users Say Thank You to MartinK For This Useful Post:
Flandry, ikirk, jj0, nordicnurse, skykooler

petur	2011-03-14 , 12:38
Posts: 650 \| Thanked: 497 times \| Joined on Oct 2008 @ Ghent, Belgium	#568

I loaded a gpx file I recorded (3 hours, 1.3MB) which went well, then in tools I pressed the tools -> get elevation button (to see what that does) and modRana locked up - had to kill it.

The gpx file was not recorded using modRana, but other tools have no issue displaying it.

__________________
Affordable mobile internet in Belgium: Try Mobile Vikings
2 GB, 1000 SMS and 15 euro of talk time for.... 15 euro

Quote & Reply |

shady	2011-03-14 , 15:19
Posts: 284 \| Thanked: 161 times \| Joined on Dec 2009	#569

i think that one of the memory/massive i/o usage settings has uffed up my modrana .... NOOO.

ok /dram but still python sits down in memory taking up about 65 megs, while the application is running, sometimes its good to me, sometimes i have to pull the battery. but this was a recent trend, any word on python2.5 hogging memory?

Quote & Reply |

MartinK	2011-03-15 , 23:35
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#570

After some filed testing, I have identified some issues:

the new tile loading works good - even on 2,5G it is possibly to use the lowest OSM Mapnik levels with centering & rotation (note that map rotation loads much more tiles than than the ordinary view and map overlay multiplies the number of on-screen tiles by 2)
while centering is on, the screen is redrawn needlessly often - basically always, not just once a second when the position can actually change - this of course needlessly drains the battery and system resources
I have confirmed that using files instead of sqlite is really slower - I think the slowdown is caused by the way tiles that were automatically downloaded are stored.
Sqlite stores the tiles sequentially, one at a time. But when storing to files, it works asynchronously - many tiles could be in the process of being stored at once, causing significant I/O load (note how the UI is similarly less responsive while the application manager does its I/O intensive work). Solution ? Store the tiles sequentially and possibly don't save tiles once the saving queue hits some upper bound as to avoid a memory leak.

New version can be expected soon, once the needless redrawing bug is fixed and sequential file storage is implemented & tested.

Originally Posted by petur

I loaded a gpx file I recorded (3 hours, 1.3MB) which went well, then in tools I pressed the tools -> get elevation button (to see what that does) and modRana locked up - had to kill it.

The gpx file was not recorded using modRana, but other tools have no issue displaying it.

Well - this is because the "get elevation" feature is not yet asynchronous - it blocks until is is done - which might be after some time, considering how many points are there in the tracklog (1 point per second -> 3600*3 ?). It might also just error out after a while, if it hits the geonames usage limit

I'll make this asynchronous once the other current issues are solved