Layers, transparency & stuff

[Maki]

Hi all,

I'd like to share some thoughts about recent tests with the new rendertheme and the latest OruxMaps beta. This is not really to ask new features, I wouldn't even know what to ask exactly, just food for thought.

The first thing is about mapstyles and overlays. Overlays aren't actually that, since elements in them can have very different z-indexes. This is a strength in some ways, for example we control at the same time the display of rivers (below almost anything else) and their labels (on top); but it has a serious drawback in that we need to clear the cache each time an overlay is switched on/off. Given the general slowness of MF we just cannot use this feature for things that could benefit from a quick on/off action (toggling hotel icons). I think that in some way this shoud be addressed in the future evolution of the library.

The second thing is about the alpha channel management. Recently OruxMaps beta introduced the ability to create composite maps for offline maps. There are still some limits but we did some experimenting to take advantage of the transparent background option. The first thing I notice is that a transparent background is painted on black, rather than on white as I would expect, and I verified this also in Cruiser. Then it appears that we cannot have a partially opaque map background, it's either on or off depending on a flag set by the app. Furthermore the map-background attribute is on the <rendertheme> tag so we can't put a category there.

Experiments meant to paint the MF map on top of an hill-shade in mbtiles have been frustrating. The attempt was to use semitransparent textures and fully opaque foreground, but it fails because in maps that have the "natural=nosea" we can use that to paint a background, but then we have forests on top, and that sums up. One possible solution would be to enable different blending modes (multiply, overlay, etc) but it may mean add quite a bit of complication. Another possible solution would involve the ability to create layers meant to work like in AutoCAD or Photoshop so that we can apply a global transparency to the whole layer instead of the single elements. Since these layers could be cached separately it could  also speed-up the use of map-styles: for example hotels are put on a dedicated layers that can be toggled on/off without redrawing the whole map.

On the other hand, getting rid of all the background stuff and only painting higways on top of other maps worked beautifully, and it seems that new label/symbol management works very well too.

Just my two cents.

Maki

[Emux]

Hi Maki,

Thanks for the feedback (I already checked the posts in Orux forum).

About the cache, it all comes down to how Mapsforge caches the rendered tiles.
They are "bitmap" files with all the information in them, that's why any model change should be after a cache reset.
But that's internal handling - other apps that use from Mapsforge only the rendering mechanism in their own map view can differentiate here (I think Orux works that way?).

About the alpha I'm aware of an issue that worked before.

I just checked your zip in Atlas and see black too.
Though I'm not sure what to expect seeing, probably the default color of the Android / Java container below.

--
Emux
Cruiser - Atlas

[Maki]

Il giorno martedì 24 marzo 2015 08:58:01 UTC+1, Emux ha scritto:

About the cache, it all comes down to how Mapsforge caches the rendered tiles.
They are "bitmap" files with all the information in them, that's why any model change should be after a cache reset.
But that's internal handling - other apps that use from Mapsforge only the rendering mechanism in their own map view can differentiate here (I think Orux works that way?).

 

Sorry, I haven't been clear. Let's say that I have a map that stacks these elements in this order from top to bottom:

- symbols & captions

- highways

- water bodies

- land cover

Currently in MF all these elements are painted on top of each other, then the resulting bitmap is stored in the cache as a single RGBA PNG. If I turn off some stuff (using mapstyles), as you say, the whole cache has to be cleared because MF can't subtract from the cached image the stuff I turned off. Now, there are two cases:

1) this stuff has different z-indexes. For example I turn off the display of forests which means areas, with a very low z-index, and their labels, with a higher z-index.

2) this stuff has the same z-index. For example I turn off the display of hotels, or water taps.

In the first case, unless we cache every element separately (which is probably suicidal), we have to redraw everything, and that's fine.

In the second case, however, the hotels or the water taps could be conveniently cached separately. Toggling them on/off would not require any clearing/redrawing of the cache, so it could be almost instant. Given the nature of the image (mostly empty areas that compress like crazy) the size overhead would be small.

Of course it should be up to the theme designer to define what has to be drawn on a separate layer. I want to stress that I'm not criticizing the current system, the ability to filter on a category across very different z-indexes (like in the first case) is a powerful tool, it just doesn't fit every situation.

Another advantage of defining physically separate layers is that we could use creative blending modes on the whole layer. If the integration with raster data (hillshading) eventually comes to MF that will be almost necessary. A typical situation would be a bottom layer with landcover (that can be multiplied with the raster hill-shading), a mid layer with the bulk of the map, an some symbol/label layers on top.

I just checked your zip in Atlas and see black too.
Though I'm not sure what to expect seeing, probably the default color of the Android / Java container below.

I suppose it's "natural" to expect that color to be white, unless we are painting on top of something else. If anything it would allow to use the same theme both with and without transparency, especially since we can't control the background well in the theme. I realize this is a choice that belongs to the app, but maybe a recommended behavior would help to uniform apps. Or maybe moving the background color in a place where it can be controlled via categories.

[Ludwig]

That would all be nice, but the problem that we have is that we do not have enough memory for full screen map display multiple times. That was the problem with the old overlays and essentially it was a disaster waiting to happen even with one overlay.

With some sort of different access to the data and a bit of overdrawing around the edges for scrolling, it might be much quicker to redraw everything all the time. Games do this and maybe so should we. It would solve lots of other problems too (rotation for one).

Ludwig

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/805d9cd3-b415-408d-9faa-5a1e0304d362%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Emux]

Besides what Ludwig correctly mentioned, the LabelLayer has a separation of labels / symbols drawing from the below map.

It's now fast enough but not without its issues (e.g. missed drawing).
That's why I exposed it in last Cruiser / Atlas settings in order to get more feedback.

[Maki]

Il giorno martedì 24 marzo 2015 23:31:48 UTC+1, Ludwig ha scritto:

That would all be nice, but the problem that we have is that we do not have enough memory for full screen map display multiple times. That was the problem with the old overlays and essentially it was a disaster waiting to happen even with one overlay.

I don't understand. Why would you need "full screen map display multiple times"? You do the assembly one tile at a time. With an average 512px tile that's 1MB uncompressed per layer, and you only blend the layers two at a time, starting from the bottom.

The only problem I see is that, due to the collision detection, label layers would actually be different depending on the categories combination, but I believe it could be worked around. In the worst case scenario you need to completely redraw the labels, but you still save the time needed to draw the base map.

Maki