- User Since
- Sep 8 2015, 2:26 PM (97 w, 5 d)
Sun, Jul 2
Jun 12 2017
May 15 2017
Dec 17 2016
I don't see the big advantage of this approach. Both approaches have their advantages and disadvantages: For the inverted approach you have flicker for coast- and sea areas (which looks equally bad and odd to me). Implementing the inverted approach will have a slight performance advantage if we don't manage the background color in a more sophisticated way. Implementing the inverted approach means on the other side that we have to develop a special dedicated plugin that will paint the pole caps blue - to avoid landmass-white circular polecaps beyond +/-85 degs latitude.
Dec 11 2016
Dec 10 2016
Dec 9 2016
Dec 8 2016
Dec 7 2016
Dec 5 2016
Dec 4 2016
Dec 3 2016
Dec 2 2016
I've tested you patch and the only thing left to complete this task seems to be the compilation warning above. Apart from that it looks great.
Sorry, still a nitpick: during compilation I get this:
Nice, still some minor nitpicks.
Dec 1 2016
Nice start :-) I guess that's a successful liftoff for our rocket!
Nov 30 2016
Nov 29 2016
Nov 28 2016
Nov 27 2016
Nov 26 2016
Nov 23 2016
I've taken the low-hanging fruit:
So I benchmarked the Mercator projection on my desktop PC. AbstractProjection::geoCoordinates() uses MarbleMath::gd() while AbstractProjection::screenCoordinates() uses its inverse MarbleMath::gdInv().
Since screenCoordinates is used by far most of the time we put our focus on gdInv:
Nov 22 2016
Implemented and merged.
Nov 21 2016
Nov 19 2016
Currently the house numbers are drawn as part of the building rendering. This results in expensive pen/brush/state changes and should be avoided.
Nov 15 2016
- Stars should be sorted on Startup by Magnitude
- Stars should be painted in batches by magnitude (and color).
- There should be a cut-off magnitude that is lower on mobile devices than on the desktop where the whole magnitude range is displayed.