long track sluggishness

[stefan]

hi scott.

i´m currently on an extended skiing trip in the european alps. pathaway records each day and has a really hard time doing so.

if you want your runs to look anything better than just two dots, you need to record at least each second. a daily tracks gets very large, even when i go back to 30s recording for the skilift uphills. couple of thousand points easily.

pathaway gets unusable with such a track. unusable to a point when even calling the main menu is impossible. i suppose all available processing power is spent elsewhere.

i´m a bit at loss as to what would requie O(n) or worse computing power when recording. maybe you could explain.

is it the drawing? does pw always render all track points when a new one is added or when the map moves? might i suggest a something more sophisticated here? pw could, for example, measure the time required for a redraw. if its beyond a threshold (eg 0.1s), only the last 100 points would be drawn completely. the next-to-last 100 would skip every other point, the next would only render 1 in 4, etc. time measuring would make it completely intelligent and auto-adapt to either slow or fast pocketpcs.

this way, one would always see the complete track, most recent part in full detail, older parts with lesser detail. and pathaway would still remain functional instead of becoming an unresponsive monster that will only react on a task kill.

stefan.

[Ahto]

Yes, this is problem also when driving by car. The only solution I see is to deactivate your older tracks so they are not displayed on map plus if still poor performance then active track must be split.

[stefan]

deactivating other tracks doesnt help. pathaway dies the sluggishness death even with just one large track in the database. and we're not talking millions of points here, just a few thousand is enough to kill the most modern pocketpc. thats really a bit weird, given that we're at over 600 mhz and a decent amount of memory today. a commodore 64 could handle that easily .

as for manual splitting, it feels a bit weird to perform such kind of operation as a user. pw design should be intelligent enough to not require me to help it with handling its databases & memory.

btw, the same story is true for ttqv. it gets horribly slow with just a couple of thousand points, on 2 ghz and practically unlimited main memory. i fear it's because they stuff everything in some sort of sql databases and use expensive transactions on each single point for each single access. i do have quite some experience in programming resource-limited embedded devices and stuff like this tends to drive me mad. its really beyond me how one can bring a modern desktop machine to a grinding halt with just some points. ttqv surely gets a price for the most inefficient code ever produced .

[Scott]

Hi Stefan,
I am assuming you are using a view that displays the entire track. PathAway does cache the active track in blocks so that it does'nt need to draw the entire track on each refresh (only the visible portions). If you are viewing the entire track then all of the points in the track cache would need to be rendered. We are working to improve the performance in this case.

Thanks for your input.

[stefan]

ah ok, so it's indeed the drawing that eats the cpu. well, zooming in isnt really helpful, since you lose all idea on where to go next. its also a bit dangerous to "lose" pathaway to cpu-eating nirvana when you accidently zoom out .

glad to hear you're working on it. good luck!

btw... about accidently zooming out... this is also a good way to lose pathaway to cpu-nirvana, even without a track .

[stefan]

just thinking... maybe only rendering single points instead of lines from point to point might also help with the performance. lines dont matter anyway when there's a thousand track points on screen. dont know if ppcs have hw support for line rendering, the suggestion might be useless then.

oh... speaking of rendering... how about outline colors? i know this will probably kill performace again, but it would make things so much more visible .

and how's that ecw support coming along? my next trip will involve between 5 and 8 countries. just thinking about creating the necessary... hrm... 5000(??) .PRC files gives me the creeps

[Ahto]

Perhaps it is currently slow because the database IO is very slow. If that is the case probably it is better to load all track points to memory at once or at least in bigger chunks. It is slower to start up but performance will be better and this kind of info does not take too much memory. So when map is moved or zoomed out, track data is already in memory and not read from database.