Active Topics

 



Notices
Page 57 of 207 « First 475556 57 585967 Last »
Reply
Thread Tools
petur is offline 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
 

The Following User Says Thank You to petur For This Useful Post:
nordicnurse is offline nordicnurse
2011-03-09 , 18:46
Posts: 7 | Thanked: 5 times | Joined on Jan 2010
#562
Originally Posted by petur View Post
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.
 
MartinK is offline MartinK
2011-03-09 , 22:35
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#563
Originally Posted by skykooler View Post
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 View Post
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 View Post
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 View Post
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 View Post
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 View Post
(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)
 

The Following 3 Users Say Thank You to MartinK For This Useful Post:
nordicnurse is offline nordicnurse
2011-03-11 , 18:46
Posts: 7 | Thanked: 5 times | Joined on Jan 2010
#564
Originally Posted by MartinK View Post
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.
 

The Following User Says Thank You to nordicnurse For This Useful Post:
jj0 is offline jj0
2011-03-11 , 19:23
Posts: 73 | Thanked: 33 times | Joined on Nov 2010
#565
Originally Posted by MartinK View Post
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...
 

The Following User Says Thank You to jj0 For This Useful Post:
skykooler is offline 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.
 
MartinK is offline 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
__________________
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)
 

The Following 5 Users Say Thank You to MartinK For This Useful Post:
petur is offline 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
 
shady is offline 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?
 
MartinK is offline 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 View Post
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
__________________
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)
 

The Following 5 Users Say Thank You to MartinK For This Useful Post:
Reply
Page 57 of 207 « First 475556 57 585967 Last »

Tags
bada rox, martin_rocks, modrana, navigation, openstreetmap, the best, wehasgps

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 15:11.

Contact Us - Home - Archive - Top