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.

In the end we will need a more sophisticated approach for either solution:

• The default background color should be chosen depending on whether most of the surrounding area is landmass or sea. This could be done using a coarse lookup pixmap. Depending on which background color would be chosen we would would leave out painting the background that is stored inside the tile.
• For the zoom-level change we will also need dedicated treatment anyways: We should keep lower-zoom tiles around and render them while the target-zoom level loading progress hasn't reached at least 50%. During loading the new target-zoom level tiles should stay visible=false while the lowerzoom level tiles are shown instead.

Again I think that these tweaks will be absolutely necessary for both solutions to deliver a decent browsing experience. So implementing the invert landmass approach is imho redundant and just an extra roundtrip.

The vast majority of users will only look at landmass tiles. So we should optimize for that, and glitches in coast and sea areas can be easier tolerated than glitches at land areas.

The inverted approach does not only have an advantage in rendering time, but also an advantage in storage consumption (and likewise download time and RAM consumption goes down).

Handling pole caps can be easily added to GroundLayer::render().

The zoom level change has nothing to do with this.