maemo.org - Talk - View Single Post - [Announce] modRana: a flexible GPS navigation system

MartinK	2010-12-09 , 01:33
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#389

Originally Posted by gkuenning

However, after a bit of exploring, I found that I could modify mod_textEntry.py to fix the problem. After the line:
Code:
      entry.set_text(initialText)
I added the following hack:
Code:
      entry.modify_text(gtk.STATE_NORMAL, gtk.gdk.color_parse('#ffffff'))
Of course, that's just a hack; it's (almost) as bad to have the color forced to white as to have it forced to black, since it won't work on light-colored themes. The proper solution would be to choose a color based on (1) the theme or user default, if specified; (2) white, if the overall brightness of the background is dark, or (3) black, if the overall brightness is light. But I'm not a gtk honcho, so I don't know how to write that code.

Hopefully, this post will give somebody who knows more about gtk what they need to fix this bug.

Well, I actually used your "hack" in the end

But I've forced not only the text color, but also the background color:

Code:

entry.modify_text(gtk.STATE_NORMAL, gtk.gdk.color_parse('black'))
entry.modify_base(gtk.STATE_NORMAL, gtk.gdk.color_parse('white'))

The text should be always readable with this, the only slight downside is that it won't respect the current theme.

Originally Posted by jj0

I've been having lots of these and it is not related to moving. But seems many processes are started and they don't die.

What happens to me, I just try to prenavigate an area where I'll be going, basically just look at the map, move the cursor around. After a set period of time of doing this, let's say 10 minutes, it will always black when moving further, i.e. you move the screen more to a new area let's say south of where you are looking, and it turns completely back. If you move it back south to where you were before the move, the tiles appear. It would seem like a memory leak or something.

Anyhow this happens when driving also, notably, when autocentered, the map would turn black, when clicking on the screen, which turned the autocenter off, the map would appear, and the moving cursor, too. Then as I'd be driving it'd move of the map, autocenter again - black, click the screen - the map is there, if autocenter right away - black... And so on...

Very annoying... It looks to bee like too many concurrent processes, or don't know, but it's not downloading the tiles, as they are already there, but still black...

Originally Posted by woody14619

The 30 second thing would fit in place with what I saw. I also had an issue near the end of the trip where it was on/routing for 4+ hours where it complained about "Operation canceled due to lack of memory". I "fixed" that by closing and restarting the app though, as I was semi-lost at the time.

I have found a few issues in the tile drawing and automatic tile download code:

no limit on number of download threads
(this means, that for every tile you have seen and don't have in local storage, a download thread was launched - which is bad if you are on a slow and unreliable connection)
some threads that error out are not removed from the thread list
once the in-memory tile cache fills up, it is trimmed each time a new tile is added
the tile drawing code is doing all the tile loading that lags the GUI when moving quickly or when entering an area that is not cached (zooming, etc.)

To fix these issues, I have for V0.20-1 rewritten a substantial part of the responsible code

there is now a (user configurable) maximum number of threads for automatic tile download
tile that are waiting for download slot are indicated by a blue special tile
old (>30s) unfulfilled download requests time out and are removed
the new tile drawing method is non-blocking -> less lag while dragging the map
all tile loading was moved to a worker thread
once the in-memory cache fills up, a given amount of oldest tiles is batch removed -> cache trimming does not needlessly run all the time like this

Hope it helps But my subjective testing seems to indicate better responsiveness so far.

Originally Posted by romanianusa

So this is not a voice nag app right?

Do you mean voice navigation ? Well, yes, there is a "basic but evolving" voice navigation available in modRana

Originally Posted by woody14619

I will... how big are the logs it generates with normal usage? If they're small I may just turn it on and let it log everything, then chop out the parts I need later for issues.

Well, it depends

Normal usage shouldn't be that spammy as usually only important events (like pressing a button, reaching a turn while navigating, receiving routing results) produce a message. But the batch download feature is quite spammy, producing a steady stream of status messages while download or size estimation are in progress.

Also, as the log files are stored in MyDocs - I'd say there should be no space issues

Originally Posted by woody14619

(I need an on-screen debug widget/button! )

Well, this should be quite easy to do, once the needed improved widgets architecture is in place

Originally Posted by woody14619

Wow.. nice map. What profiler are you using to generate that? Is it just for python? I code mainly in C/C#/C++, so not too familiar with python and it's tool set. Nice look to it though.

I use a simple script that first starts modRana through cProfile to get the profiling data. Then it uses Gprof2Dot to convert the profiling data into that nice graph/map

cProfile is python specific, but Gprof2Dot seems to support many different profilers.

Originally Posted by woody14619

Hmm... Odd. It's been much better about warning 3 to 4 miles out since the update to 19. Maybe it works better on trips with longer distances between points? Is the length of the segment used at all to compute how early to trigger?

Well, modRana still uses precomputed values it gets with the directions data from Google. I guess they take the directions type, segment length + some assumed movement speed into account.

But its still just a guess,
locally computed trigger distances would be definitely better, as they can reflect all the locally available variables, like real current and average speed. I even got a rough algorithm for this from a user/developer a while ago:

(as image since the forum was eating the formatting)

Originally Posted by woody14619

Overall, sounds like you've got plenty on the plate to work with. I'll happily test things out with new releases as they come out! I'm also hopeful to getting things setup (build env, etc) this weekend to start porting the tile server. I probably won't have a release before Monday, but if things go smoothly... we'll see.

OK then, fingers crossed that everything goes smoothly

__________________
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 4 Users Say Thank You to MartinK For This Useful Post:
jj0, SubCore, Wikiwide, woody14619