- User Since
- Sep 8 2015, 2:26 PM (80 w, 2 d)
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.
Nov 14 2016
Nov 13 2016
Nov 12 2016
Nov 11 2016
Nov 10 2016
Looks good to me in general :) I trust you on the details :)
Nov 9 2016
Oct 28 2016
Oct 27 2016
Oct 6 2016
Oct 5 2016
Oct 2 2016
Right now we seem to instantiate three relatively expensive texture-related objects
Sep 15 2016
Q1: Error/out-of-bounds handling?
Where to handle bad input data, like out-of-bound values?
Q3: Always use Gudermannian function?