Excellent!

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.

In D3563#66539, @Rakete1111 wrote:

Didn't know about isEmpty(), but should have, I feel bad now...
If by OSD you mean the notifications from KDE, I don't think it is necessary: Unix users can always look at the debug output, just Windows users would have to debug the application to get those messages, so that's why a QMessageBox is better for them I figure.

Nice start :-) I guess that's a successful liftoff for our rocket!

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:

Implemented and merged.

Currently the house numbers are drawn as part of the building rendering. This results in expensive pen/brush/state changes and should be avoided.

• 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.

Looks good to me in general :) I trust you on the details :)

Right now we seem to instantiate three relatively expensive texture-related objects

Q1: Error/out-of-bounds handling?
Where to handle bad input data, like out-of-bound values?

Q3: Always use Gudermannian function?