Notices

Has anyone had a chance to try out optimised version on the road? I was really hoping to give it a whirl today to see if it does a better job of keeping up. Unfortunately the UK is incapacitated by a very small amount of snow. ;-) So no driving for me.

dwould,

Tried it this morning, maybe a little snappier on routing. Still a little behind while driving (using follow=3) 50-75% cpu usage spikes. Very similar to current svn.

Menu is still slow to load each screen, however very quick between screens once loaded. Slow to load again next time menu is accessed. Is this the same kind response you are seeing?

Doesn't appear to exit cleanly if using the close "x" in window mode. I thought one of gerritv's fixes addressed that.

I uninstalled / re-installed using your package (checked /usr/share/navit to be sure uninstall was complete.

Hi Lemmyslender,
interesting I find the menu very fast to load screens now, first time and everytime.

what is the effect of higher numbers in follow? I assumed it was 1=on anything else off.

As far as exiting cleanly I may not of picked up gerritv's fix for that, don't know if it made it into svn.

Another thing I did, which may or may not be relevant was remove all the debug entries in the config. but I wouldn't of thought that would make much difference.

dwould,

I saw somewhere, this thread perhaps? that using higher numbers for follow would make it more usable on the n8x0. I find that using 1, the screen stays centered better, smoother movement, but takes longer to update reroutes, longer delay getting into menu, zooming, etc. Using 3, the position icon "moves" down the screen 3 times, then is updated to current position (complete screen redraw), roughly 2-3 seconds. This makes the response time a little quicker, I think. I did try 10, but felt that was maybe too long and didn't improve response times any.

Tapping on the screen takes 3-4 seconds for the menu to appear. Tapping action takes another 3-4 seconds for the menu to change. Tapping the house icon is almost instantaneous going back to the main menu. Tapping action again takes another 3-4 seconds.

Good/Bad/Overly optimistic?

Ok, I don't have a gps fix right now, so I'm trying without any routing etc etc. But with no fix, I get instant menu response. I'll stick it by a window and see if I get a signal so I can plot a route and see what that does to the responsiveness. I might also double check I put the *right* version on my server...

I get the same responsiveness with and without a signal. Thanks for checking.

did some more investigation. It seems that getting a gps fix hits my performance of the first menu load, back to a couple of seconds. I tried using the demo 'vehicle' and it didn't take this hit. So something in the interaction with real GPS is having an impact beyond just the redrawing of the screen for updated location etc. I am wondering if my n810 with built in gps gives a different performance profile to an 800 with bluetooth gps.

I've tried to wrap my head around what goes on in the gpsd vehicle code and I think I understand it. looks reasonably sensible. the gpsd calls it's callback method with new data. And we only read/set it if it's changed since our last read. Then separately something else calls another callback which returns the last held value for which ever attribute it wants.
don't know why that would be any slower than what the demo vehicle does. unless just having the gpsd itself has a significant performance hit.

Think I might switch debug statements on to see if it shows up any odd patterns.

On a completely separate note, I've added some info to my blog page about setting up the blue 'route' line to be thin and on top of the road rather than fat and underneath it. The wiki does allude to this option and I figured someone might be interested: http://danielwould.wordpress.com/navit-stuff/
I thought about updating the wiki with this information, just to highlight it, but I'm not sure where it would really sit.

dwould-

I apologize. In my tinkering, I had changed my icon size (icon_xs,_s,_l) to a non-standard value (60) as I was experimenting last week with changing them. Too big / too little. The default values appear to be 60,60,70 in the standard navit.xml.

Long story short, I just changed the size value to 48. WOW! Great response time on this. I guess as long as we use one of the pre-scaled values it works great. Nearly instantaneously. 8,16,32,48,96 for the record.

Sorry for any extra work I caused you.

dwould/gerritv any hints on how to compile this? I'm on Ubunutu 8.04, installed the SDK w/ scratchbox. Maemopad example compiles properly. Downloaded navit svn files. Added gerritv's debian folder to navit directory, and maemo.compile. How to proceed? I get a variety of errors from there. Any tricks I'm missing?

Ahha! that would do it. Yes Gerrits fix was to prefer the pre-scaled images. to save the cost of rendering svgs to side. So if there isn't a pre-scaled icon you don't get the benefit.

As far as compiling goes, I largely followed the instructions Gerrit added to the navit wiki : http://wiki.navit-project.org/index....t_on_n770/n800

That said at this point I've re-installed my whole scratchbox environment at least once! ;-)
what sort of problems are you having?

Hi
Post your output to pastebin.com and put a link here. There are warnings that you can ignore and then there are ones that you can't :-).
autogen and configure should produce no errors, just lots of commentary output. Basically it is:
export SBOX_DEFAULT_AUTOMAKE=1.9
./autogen.sh && ./configure <lots of options> && make in the top level directory. Once you have done this once, then you can do the .deb build.

I will try tonight to update the wiki and my blog with current info on compiling, pre-requisites, running gpsd on Ubuntu so you can test within Scratchbox etc. before I forget the stuff.