Display Model and scaling problems

[Andre Höpfner]

I have two images, which are intended to illustrate the problems of scale.

left = scale factor 1

right = scale factor 2

 

problem 1

Symbol, the symbol here is not scaled!

 

Area shader bitmap

Also the shader bitmap is not scaled for an area.

 

DashPathEffect

The distances between the DashPathEffect should be scaled.

 

Text

I'm not quite sure, but I think that here the thick font and the thickness of the border also do not quite fit!

 

First, I think that the class DisplayModel should be completely static, so you can access the values ​​from each class out.

 

Furthermore, the bitmap interface should implement the method boolean mustSscale ().

 

If I want to provide a Patch to what source should I take here?

Greeting Andre

[Ludwig]

Hi Andre,

png files are not scaled and I am not even sure if they should scale as they are unlikely to look good (at least not when you are moving to factor 3 or so). 

So far I have only tried my SVG stuff with the icons, not with the shaders (because I had no SVG files for them). If someone could provide some SVG files for the patterns that are used in the internal render theme, we could give that a try (they would not have to look exactly the same).

The DisplayModel cannot actually be static as different mapViews can have different DisplayModels, but you can access the DisplayModel for each mapView via the getModel().displayModel accessor. 

A patch that improves the rendering would be welcome, whether it would make it into 0.4 would really depend on large the changes are that you are proposing.

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/25bcd599-d36b-4610-ac64-b7f263933fc6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Andre Höpfner]

You are right, but there are many themes which are not running with SVG.

I think here it is nevertheless necessary to scale!

 

I would try here to keep the changes as small as possible.

But on what basis? (Which repository?)

[Ludwig]

You can still use Rescue as the base, I have not made any further changes. 

We can try how it looks if we just scale the pngs.

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/3dfd755c-9cc9-42ae-93c0-f3e63adf7032%40googlegroups.com.

[emux]

Hi,

Another idea would be that instead of scaling the png,
to have them at different dpi like drawables at Android res folder.

e.g. Maki's Tiramisù theme has 3 versions that differ only at symbol size.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Ludwig]

Yes, I have been thinking about that. We would need to find a way of hooking into the Android resources selection system, that way the best one could be automagically chosen. But that is definitely not 0.4.

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/9ceb2a72-b7f4-4082-82b5-56b004514daf%40googlegroups.com.

[Maki]

e.g. Maki's Tiramisù theme has 3 versions that differ only at symbol size

Yes, but that's not optimal either. An S4 user will use ZL-18 to see the same area that an S3 user sees at ZL-17 (more or less) and this compensates for the fact that the S4 icons are bigger (in pixels). However to do things properly one should also adjust the zoom level of appearance of the symbols, but that's a lot of work. I'm talking about 0.30 here, I have the impression that Rescue will solve this with variable tile size, right?

Scaling is a real problem. Sometimes you want things to scale, sometimes not...

Icons should not scale while zooming. At higher zoom levels, keeping the symbols to the same size means the ability to display more symbols. On the other hand we have the problem of different display densities. There icons should scale, but resizing PNGs is a bad idea: heavy resizing works on photos, but not on small computer generated images with sharp transitions. I think there is a quick and dirty way to use multiple PNGs, without building different themes for different resolutions.  We can just put the icon files in the same folder with a suffix that indicates the corresponding scale factor (x10 to avoid decimals). So "Symbol.10.png" is the base symbol and "Symbol.15.png" is the same symbol rendered at 150%. Mapsforge should use the one that's closer to the ideal one to match the device's dpi.

For textures it's different. If you have pseudo-realistic graphics then you most likely want them to grow according to the zoom-level otherwise things will go out of proportion and look bad (eg. trees smaller than roads). Most of my patterns have two or three sizes for that reason. There I think that SVG would be the killer solution, since it can scale freely and a little blurriness isn't going to be noticed. It could probably help to resolve the problem of seamless tiles (just scale to fit when it doesn't match exactly). However there may be cases when you don't want that to happen, so the RenderTheme API should IMHO allow the designer to chose what to do.

Ludwig, I can generate a couple of test patterns in SVG without problems, can you give me a PNG example of what you need?

And then the dash-stroke. It really should scale by default when zooming. It is very annoying to have the line width scale and the stroke not. To keep things in proportion a lot of unnecessary rules have to be set multiple times for the different zoom levels. A parameter like the Scale-radius would be extremely useful (also for width). Maybe with a scale factor rather than a boolean value.

Best regards,

Maki. 

[Ludwig]

I have been playing a bit with this and to address some of the issues Andre raised I have pushed a fix to a new branch on my server:

http://code.google.com/r/ludwigbrinckmann-mapsforge/source/list?name=rescue-exp

The fixes are for the dash-array (now scaled) and for the back paint of labels etc. I think the dash-arrays are clearer now and scaling the back-paint also makes labels stand out better. 

I have also changed a few surrounding methods, so that the DisplayModel is always there. This should make it easier if someone wanted to experiment with this a bit more.

These changes are relatively small, so they could go into 0.4, but I would like to do this only if we agree on this and there is no adverse side effect (more eyes help). (At this stage I do not want any changes to the render theme xml).

I continue to be against trying to scale PNGs and I think the solution to the textures is to have SVG files that are designed to cover an entire tile (but then memory issues might come along...). 

To test this, Maki, I would like to take up your offer of producing SVG files for some textures. In the internal render theme we have textures for different types of forest, parks, military etc, but I am pretty sure that you could produce better looking textures (so do not take them as a starting point, they were chosen because they were there, not because they looked good).

I will use this new branch for those changes where I am not certain if they will go into 0.4. I will keep merging in the official rescue branch into it.

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/551bc16c-41f4-4bed-965f-494191e4b459%40googlegroups.com.

[Ludwig]

Just pushed another commit for this that moves scaling of text and stroke into the same position (so far it was done centrally via the RenderThemeBuilder), this should ensure that the scale factors remain consistent. If this causes any trouble, let me know.

Ludwig

[emux]

Hi Ludwig,

An off topic note regarding your repository.
The RSS feeds do not seem to work.

Mapsforge repository has feeds for issues, source updates etc
They are really convenient for receiving various events.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Ludwig]

RSS feeds: I have no idea where I would configure that. (I looked, but I cannot see anything related to feeds generated)

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/ecc2bbab-89dc-41cb-9024-14f6f13bfb52%40googlegroups.com.

[emux]

Hi,

I had to update my scripts to include also the rescue-exp branch to the other mapsforge builds I play with :-)
Ludwig is this the new branch where the new development will be, as you mentioned?

Regarding the changes, I attach 2 screenshots (at 320 dpi) showing the same place with exact positioning:
- rescue.png is Cruiser Beta using rescue branch
- rescue-exp.png is a Map Viewer using rescue-exp branch
The differences are obvious at dash array and labels (with dark backgrounds).

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Maki]

To test this, Maki, I would like to take up your offer of producing SVG files for some textures. In the internal render theme we have textures for different types of forest, parks, military etc, but I am pretty sure that you could produce better looking textures (so do not take them as a starting point, they were chosen because they were there, not because they looked good).

Try these to see how they go, especially in terms of size. I'm afraid the one with gradients will not work so I made a flat one.

Making patterns as big as tile size would be even better in terms of aesthetics but the file size grows fast. The woods pattern is 8x the corresponding PNG. However since it scales you only need one copy instead of the three I'm using now in my theme. And only one file to edit in case of changes.

I think a possible approach could be dividing the tile size by the pattern size, round the result and stretch the pattern accordingly. Let's say that the tile size on a particular device is 332px and the pattern is 128. Since 332/128=2.56 you shrink the pattern a bit to fit it 3. So you can keep file sizes down and still have seamless patterns with variable tile size.

Let me know if you need mods on the files.

Maki

[Ludwig]

Emux, thanks for attaching the screenshots, I should have done that myself.

The change is as I intended, so just want to confirm that this would solve both the Dash-array issue and the backpaint issue for labels, that Andre reported? 

Ludwig

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/57d06e31-94ed-4b72-8841-c0815ef4adbe%40googlegroups.com.

[Tobias]

Thanks for that solution for dash-array and backpaint, Ludwig, that's also an issue I encountered (but learned to live with). Much more consistent rendering. I'd like to see that in 0.4 if there aren't any issues.
Tobias

[Ludwig]

I have just pushed two commits to rescue-exp that address these issues.

The first commit e2cac51c8c124d6b adds the capability to clamp the tile size to multiples of a fixed value, e.g. 

displayModel.setTileSizeMultiple(100)

will result in possible tile sizes of 100, 200, 300... with the tilesize rounded to the closest value. 

There is an example for this in the Samples app.

The second change 6b09f1db971cd637a is of an experimental nature and currently requires a hack to work as there is not yet support in the rendertheme xml for it. It renders SVG files in the patterns folder up to the fixed multiple for tile sizes and uses that as an area texture (other SVG files are not affected). 

The SVG Textures example uses a modified rendertheme to show the textures that Maki made. 

To really support this we will need to make some changes to the rendertheme xml, so this will definitely not go into 0.4

Ludwig

[Andre Höpfner]

Sorry, but I no longer savvy.

What is now the branch should I test?

mapsforge / rescue

or

ludwigbrinckmann-mapsforge/rescue

or at least

ludwigbrinckmann-mapsforge/rescue-exp

[emux]

Hi,

rescue branch is now at main mapsforge repository:
http://code.google.com/p/mapsforge/source/browse/?name=rescue
git clone -b rescue https://code.google.com/p/mapsforge/

The above experimental changes are at rescue-exp branch:
http://code.google.com/r/ludwigbrinckmann-mapsforge/source/browse?name=rescue-exp
git clone -b rescue-exp https://code.google.com/r/ludwigbrinckmann-mapsforge/

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Andre Höpfner]

I have now tried many days to find a good solution.

I think that the proper place for the processing of a possible scaling is the CanvasRasterer , since virtually all drawing tasks to be done.

That's why I passed on the constructors of DatabaseRenderer and CanvasRasterer the current DisplayModel.

 

Here it can be decided then for each task, whether scales must be.

 

In my patch I did this once implemented only for the symbols , since I do not know if you are agree or may have another solution.

In order to decide whether a symbol has to be scaled, I have the interface Bitmap passed a new method signature. { boolean mustScale () }

In the individual derivatives can now be scaled the decision be given back .

For instance, a AndroidSvgBitmap not be scaled and always returns False .

The other bitmap derivatives give only returns a true if they were not scaled about scaleTo ().

 

I have created the patch here only for the core. To create an instance of the DatabasRenderer  in Android and AWT as samples has yet to be made ​​. This I have not in my Eclipse.

 

 

 

Greeting Andre

[Ludwig]

Thanks for the patch, this has not been forgotten.

I think a change to the rendertheme.xsd for render theme v4 will be one of the first things I will do once we have a 0.4 release. My assumption is that some people have learned to live with the current implementation and I am a bit wary of changing the scaling behaviour of the icons just before a release. The render theme v4 should have additional attributes to trigger scaling of pngs if that is desired.

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/8254a7d3-c326-4743-95c6-894e7345e9e4%40googlegroups.com.

[emux]

Hi,

My assumption is that some people have learned to live with the current implementation and I am a bit wary of changing the scaling behaviour of the icons just before a release. The render theme v4 should have additional attributes to trigger scaling of pngs if that is desired.

+1 for this approach.
We have to make sure (if that's possible) to not let again break the backwards render theme compatibility.
It's extremely convenient that it's corrected at rescue branch and now we can read render themes v1 and v2.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

https://www.dropbox.com/sh/hd6gvnebztifaqe/dsPpLzNRde/Applications/Atlas