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.
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.
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.
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.
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 :)
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.
The 'bounds' that I had implemeted earlier described the minimal rectangle inside which a whole track was contained. This
bounding rectangle was used to quickly cull all track types at draw-time. And it worked well... too well! The current track
is continually adding points to itself, so its bounds need to be recalculated regularly, not just at startup like other
track types.
So, I've implemented a new Renderable, 'CurrentTrack' which does the special handling for that type of track. It is
smart in that it only recalculates/updates bounding rectangle on the newly added points, so it's very quick. I tested
it on my phone and it appears to be working OK.
Other minor adjustments here and there as I tweak things.
Fixed a bug related to the distance used for line reduction. The previous value of zoom was being used, instead
of the new value. This kind of explains why I could see line reduction changes more than I though I should have
been able to. Now it's looking very nice. I don't think there will be many more changes. If any.
I've been through and cleaned up the code - minor improvements and cleanups. I'm happy with it and will I stop making
changes and wait for review. I also now understand how git branches work :) so I will work on my own branch.
I hope that this addition makes it into OsmAnd; I'm confident that it is robust and well written.
There will probably be a bug or two, but relatively minor I am sure.
I've been through and cleaned up the code - minor improvements and cleanups.
It's done. Now that I'm happy with it I propose to stop making changes and wait for review.
I also now understand how git branches work, so I will work on my own branch.
I hope that this addition makes it into OsmAnd; I'm confident that it is robust and well written.
I put a bit of effort into "pretty". Also, arrows are not displayed until a particular zoom level.
Sample video of this version with the following renderers active: rainbow altitude band, original track, distance
markers and arrows. See video at https://youtu.be/FNui0zxJGJI
Seems to be pretty solid for all renderers. Speed is good. This is close to a "final" version.
Out of memory bug happened occasionally - now fixed by writing to original canvas instead of creating its own
bitmap buffer. It's going to be a lot quicker, too. Since the altitude band is now solid, though, it should be
in the renderer list before the standard track segment.
I have also done some work on the distance/marker renderer, and that is enabled in this update. It draws the
distance (km) as a marker and number over the top of each track.
I went for a ride on my motorbike today to check out how some of the changes work. The "current track" stuff
is hopeless, so that needs to be fixed. Basically I was trying to NOT resample the current track, as it
causes all sorts of speed issues when points are continually added and resamples are continually fired. But
my change clearly didn't work properly so I will revisit that shortly.
I do urge anyone testing to try with a GPX track which has elevation data - the rainbow track backing is
quite nice I think... I hope others like it.
As a side note; I found out how to get the exception log - I have to setup an email account on my emulator
to get it to work.
It's a lot simpler - and a lot faster, I'm sure. Basically it didn't need to be as complex as it was, and mostly
the 'hard stuff' it was solving is actually fairly easily handled by the draw. So. Seems to be working fine.
There are other little tweaks here and there as I test out the system.
The renderers need to behave under density and zoom changes; so that would be the widths of things should scale
properly, and the look of some of them leave a bit to be desired. However, it's the system that is now fully
functional, and work on the renderers can come later. The main track draw seems pretty solid.
Fixed the '1st pass' flag check for the draw loop. Previously was trying to draw at negative infinity
- this *may* have been the reason this routine appeared to occaionally crash the emulator
Modified the draw so it only draws lines which are partially or completely on-screen
This routine is now optimal as far as minimising draw goes
- first cull based on limits of entire track
- second cull on per-segment basis based on screen visibility
Sitations with low point-counts may have been problematic. Now, 0, 1 and 2 point arrays are explicitly handled.
Added a copy constructor to WptPt to allow copies to be made, rather than returning original array.
Cases where no data is returned always returns a zero-sized array rather than a null array.
Just occurred to me that when zooming out (away) then the culled line we have is suitable for display. Previously when
zooming in or out, the culled line was discarded and the original line was drawn. That was to prevent you seeing really
low-resolution stuff while you wait for the asynchroous line cull to finish (can be in the order of several seconds).
However, with this modification, that is now only done when you are zooming in. This improves dramatically the "busy"
look when too much stuff is drawn for the given resolution. Anyway, simple fix but great effect. :P
This gives a simple GPX track that is drawn with asynchronous point reduction to improve the speed of display.
Also, the simple region-based culling gets rid of entire tracks from the draw pipeline for further sppedups.
Reworked all the renderers to be much more object oriented.
Got the sample arrow and conveyor renderers working
Tracked down a few bugs - particularly one still there - TrkSegment with 0 points!
This in my opinion should never happen - it's coming in from "outside" to my code.
