Commit graph

30114 commits

Author SHA1 Message Date
Hardy
98900c1ff6 small code streamlining 2016-04-04 09:48:42 +02:00
CJTmmr
6fe8e8c924 Translated using Weblate (Dutch)
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-03 21:19:50 +02:00
Ajeje Brazorf
cefbabf11d Translated using Weblate (Sardinian)
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-03 20:59:09 +02:00
sonora
455ee0775a fix stop refresh behavior 2016-04-03 17:35:54 +02:00
Andrew Davie
9f0bcf3257 MINIMAL code set for GPX line drawing
Has all the structure of the classes needed for extension to arrows/markers/whatever.
However, this is just the minimal subset of those base classes required to implement the line drawing functionality
with the asynchronous resampling, and fully compatible with 'current track' which is NOT resampled in any way.

These files are a branch from the prior pull request, and hopefully will make everyone more comfortable about including
the code. The altitude and speed displays, all the bells and whistles - that can come later if needed.
2016-04-04 00:30:07 +10:00
sonora
7933165790 try fix button appearance of GPX tracking shortcuts 2016-04-03 15:52:41 +02:00
sonora
a671d19356 use clearer string 2016-04-03 15:37:28 +02:00
ace shadow
3813183a3d Translated using Weblate (Slovak)
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-03 15:36:49 +02:00
Andrew Davie
ceddb50e60 Minimised calls to getPixXFromLatLon and getPixYFromLatLon during main draw loop
In the drawing loop, culling was performed on pixel boundaries based on x/y positions compared to the tileBox x/y position,
however calculating these from lat/lon was quite a slow process involving calls to getPixXFromLatLon and getPixYFromLatLon
which in turn had a horrendous amount of calculations happening. But since the tileBox has lat/lon and the pixel/lines being
drawn also have lat/lon it seems reasonable - despite potential spherical issues on lat/lon coordinates (?) to just use the
lat/lon as a visibility cull. So, that's what I've done and it does seem to work OK.  Heaps faster; aside from the actual
line draw we're talking a couple orders of magnitude improvement in speed.  Getting really zippy now, even when drawing
groups super big tracks, and I mean big - hundredsof thousands of points big.

The video at https://youtu.be/J1ppW3_hWds shows well over a thousand kilometers of tracks, 230 thousand points.
2016-04-03 23:31:15 +10:00
sonora
829be9901f test suppress creating extra nav notification 2016-04-03 14:49:14 +02:00
sonora
478e2512bf improve formatting 2016-04-03 14:44:52 +02:00
sonora
7b926d000a fix display 2016-04-03 13:53:47 +02:00
sonora
fef54b35d3 fix build 2016-04-03 13:17:08 +02:00
sonora
5feef3404c Display track distance in save track option in settings 2016-04-03 12:59:35 +02:00
sonora
d96505411d better comment 2016-04-03 12:35:59 +02:00
sonora
a88b9f12b0 Suppress debatable purpose trip recording notification 2016-04-03 12:16:56 +02:00
jf-simon
c0dfb730aa Translated using Weblate (German)
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-03 11:46:50 +02:00
Victor Shcherb
11a9c2df16 Fix GPX recording without plugin #2407 2016-04-03 11:55:13 +03:00
Weblate
026e6bfbb7 Merge remote-tracking branch 'origin/master' 2016-04-03 10:34:54 +02:00
Franco
5860511c6e Translated using Weblate (Spanish (Argentina))
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-03 10:34:49 +02:00
Matej U
75d399583a Translated using Weblate (Slovenian)
Currently translated at 99.9% (1955 of 1956 strings)
2016-04-03 10:34:49 +02:00
Piotr Sokół
2d189bb0be Translated using Weblate (Polish)
Currently translated at 99.8% (1953 of 1956 strings)
2016-04-03 10:34:48 +02:00
Ldm Public
5616e30875 Translated using Weblate (French)
Currently translated at 99.8% (1954 of 1956 strings)
2016-04-03 10:34:44 +02:00
josep constanti
0387161b60 Translated using Weblate (Catalan)
Currently translated at 97.7% (1912 of 1956 strings)
2016-04-03 10:34:42 +02:00
Viktar Palstsiuk
b75c6a1824 Translated using Weblate (Belarusian)
Currently translated at 99.5% (1947 of 1956 strings)
2016-04-03 10:34:42 +02:00
Victor Shcherb
520e0d12e7 Update version 2016-04-03 11:34:32 +03:00
Franco
862e183d79 Translated using Weblate (Spanish)
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-02 22:33:57 +02:00
ezjerry liao
0be0c02c3f Translated using Weblate (Traditional Chinese)
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-02 20:41:13 +02:00
Andrew Davie
209203acd3 Resample of Arrows, Speed, Altitude and Conveyor enabled
By enabling on-zoom resampling of arrows, speed, altitude and conveyor data it is possible to more effectively
tailor the visuals of these renderers. For example, the altitude and speed are point-reduced based on zoom, and now
look much cleaner at low zoom values.  Likewise, the arrows are now rendered at consistent size regardless of
zoom. Also, the conveyor segments are similar length onscreen regardless of zoom. During a zoom change, the
prevoiusly resampled track is killed, so there is a brief flash while the appropriate track is resampled. This
appeared visually better than drawing the old track with incorrect spacing/scaling.
2016-04-03 03:40:56 +10:00
Andrew Davie
3e13d309f6 "Massive" optimisation - on-demand culling for GPX tracks
A bit of inspiration; rather than trigger the culling for tracks when they are loaded and every time you zoom
(i.e, creating the resampled or simplified tracks such as standard track (Ramer Douglas Peucer line reduction), arrows,
speed, markers (all resample)... now the system uses the bounding rectangle of the original track to trigger the cull(s)
only when the track is onscreen and viewable. This now allows dozens of tracks to be loaded without initial slowdown
caused by all those resamplers and cullers running in the background. It's an on-demand system, in other words.

So, whereas previously if you had 20 GPX tracks loaded, and you zoomed in/out, then all 20 of those tracks would start
a Ramer-Douglas-Peucer resize, which would significantly slow down the whole thing (even though they are asynchronous
they do take a toll on performance).  Now, when you zoom in/out, only visible tracks (or ones which become visible)
will start the RDP resize.
2016-04-03 01:04:26 +11:00
Andrew Davie
66128c8c66 Merge remote-tracking branch 'upstream/master' 2016-04-02 22:07:21 +11:00
Andrew Davie
e88c37599a visible render layers changed 2016-04-02 20:44:16 +11:00
Andrew Davie
ff29a1a744 Optimisation. Line culler slightly quicker. 2016-04-02 20:30:59 +11:00
Andrew Davie
6371dd2da4 reconfigured to display speed render 2016-04-02 18:57:56 +11:00
Andrew Davie
4474c9421a Optimised. Checked/fixed 0/1 point boundary conditions. Fixed speed.
I've done quite a bit of refactoring on the asynchronous resamplers to optimise the code. I've also checked carefully
the boundary cases of 0 and 1 point lists and ensured that they operate OK. Fixed up the speed resampler, which was
placing results in the wrong list :)
2016-04-02 18:51:20 +11:00
Andrew Davie
aac22d9e41 Changed culled to always non-null 2016-04-02 14:04:26 +11:00
Franco
e9668d1461 Translated using Weblate (Spanish (Argentina))
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-01 21:02:45 +02:00
sonora
180f5c3714 test something 2016-04-01 17:38:27 +02:00
sonora
12815491d9 hide notification if nothing is ongoing 2016-04-01 17:15:15 +02:00
Andrew Davie
b7d826483c Paint/context preserving local state
I got to thinking that the paint variable state should be preserved after the drawing functions did their stuff. Saving
and restoring individual values inside each function was getting messy, so I implemented a local paint variable which
was updated with the important stuff from the passed-in paints. The local variable is now used for all painting/drawing
and the original paint guaranteed unchanged. I could see issues elsewhere if I changed something and other code
was assuming it was already set.  So, quite a bit of fiddling with the code to get this working, but now it's clean.

I also did a bit of work on the arrows - see video at https://youtu.be/wvE9HUDMqSM

Basically they're much nicer, but also they are coloured. It's just an experimental thing, where the colour is based
upon the distance along the track; using the same rainbow scaling as the altitude display does; that is... purple up
to red.
2016-04-02 01:55:58 +11:00
sonora
e868ebce01 remove notification line breaks for now 2016-04-01 16:47:15 +02:00
jan madsen
8dfb592b2c Translated using Weblate (Danish)
Currently translated at 100.0% (1956 of 1956 strings)
2016-04-01 16:44:54 +02:00
xmd5a
e027289d28 Update strings 2016-04-01 17:22:29 +03:00
sonora
e020df1bde small fix 2016-04-01 16:06:19 +02:00
sonora
82545c0fda see if notification takes line breaks 2016-04-01 15:59:29 +02:00
sonora
8aaaab9bad try improve weird notification behavior, particularly for GPX recording 2016-04-01 15:49:10 +02:00
GaidamakUA
5bde48b2e6 Fixed menu for configure screen. 2016-04-01 15:56:11 +03:00
Alexey Kulish
2c74e887a1 Fix https://github.com/osmandapp/Osmand/issues/2389 2016-04-01 13:04:09 +03:00
Alexey Kulish
bf1dac5b06 Fix https://github.com/osmandapp/Osmand/issues/2393 2016-04-01 12:40:37 +03:00
GaidamakUA
332167378c Partially fixed layout for configure map. 2016-04-01 12:08:20 +03:00