Scale factor for short vertices calculation

[devemux86]

Can provide some automatic MapRenderer.COORD_SCALE in high resolution screens, e.g. in MapView initialization, like do currently with Tile.SIZE.
Preferably that should be optional via Parameters, so that users can use their own in the apps.

Related to #343.

[devemux86]

Could use device dpi as guide and set MapRenderer.COORD_SCALE after any CanvasAdapter.dpi is set.
Probably keep current "8" scale as default and use "4" for high resolution / dpi screens.

[devemux86]

@Gustl22 @Longri
Can you test, any opinions for the current 420dpi limit?

[Longri]

On my App I use COORD_SCALE = 1
And I have never seen any problems!
So I think it gives no problems with calculated COORD_SCALE, if the result >1

[devemux86]

Default COORD_SCALE = 8 seems working on Desktop and Browser.
Full screen tests on 4K or 5K screens would be interesting to check. 🙂

On Android the scale 8 seems ok until 420dpi wherever was tested so far.
Above that dpi the high resolution devices require smaller scale and 4 is a sane default as next step.

[Longri]

I have only Full HD Devices!

[devemux86]

In #343 you mentioned a Note 4 1440x2560 px (~518ppi), is it available?
Or else Android emulator at 560dpi clearly shows the improvement with scale 4.

[Longri]

You are right! I will check again. But with COORD_SCALE = 1 is all fine. On Note 4!

[Gustl22]

I'll test with 4k on Monday.

[Longri]

It looks good on Galaxy Note4

Also on iOS (as dependency on my own App! iOS-example can't run on AndroidStudio)

[Longri]

But I have a scaling problem with my app!
After upgrade my app to the last vtm-snapshot, something happened with the scaling of the map elements.

The scale bar is the right size, but all map elements are too small. (On Galaxy Note4)

Which properties must/can I set?

At the moment I set

            float scaleFactor = CB.getScaledFloat(Settings.MapViewDPIFaktor.getValue());
            CanvasAdapter.dpi = CanvasAdapter.DEFAULT_DPI * scaleFactor;

[Longri]

Debug Breakpoit : CanvasAdapter.dpi = 499.99872

[devemux86]

Don't remember changing something related to map scaling lately. 🙂

But no need to set CanvasAdapter.dpi, it's set automatically on initialization.
As well as the Tile.SIZE (see here), unless want to set it explicitly.

EDIT: or see here for Android with libGDX.

[Gustl22]

We have to find a workaround to declare COORD_SCALE as final! There're some (final) constants which are initialized with first COORD_SCALE = 8.0f and aren't updated.
See AbstractVectorLayer.MAX_CLIP, LineBucket -> Renderer.COORD_SCALE_BY_DIR_SCALE, S3DBLayer.TILE_SCALE, (regular) PathLayer.MAX_CLIP.

Or find a way to handle them dynamically.

I only mention S3DBLayer. Not sure, if I made a fault there.

But MAX_CLIP should be updated to profit from the larger clip range.

I tested on 4k, but I only have a PPI of 157. So the clip is not enlarged and wouldn't be updated cause constants remain the same. This especially affects paths (and textures) with tilt up to 80 degree. So paths are cut there with regular PathLayer.

Only as question: is there a reason why low dpi devices (or very large devices with medium dpi, like 4k) cannot use 4 as COORD_SCALE ?

[devemux86]

MapRenderer.COORD_SCALE is a public static variable, could also set it externally before any library initialization, like doing with various Parameters.
Just that way the work is transferred to application from the library.
Wouldn't want to complicate all library structure just for that, need to think more the implementation.

is there a reason why low dpi devices cannot use 4 as COORD_SCALE?

No particular, just usually prefer to not change defaults that are already well / long tested.

[Longri]

First:
The scaling problem was my mistake. I have preload a Theme bevore CanvasAdapter.dpi was calculated. SORRY!

Second:
I use COORDSCALE=1, every time, every Device!
So don't set FINAL (or set Final to 1)

[Gustl22]

I meant final in terms of: once set (even if it's set by user) and never should be changed (in app) afterwards. But that's not possible for static vars, I think. So need to think more dynamically for the dependent constants :D

[devemux86]

If developer of an app "knows" and changes an "advanced" parameter, why will change it again and possibly break it? It's not logical and we're not here to cover such "strange" workflows.

Just improving things without complicate the library more.
When have more time, all these need more testing..

[devemux86]

@Gustl22 after debugging the variable values while the samples are running, I cannot find any issues with current implementation.

MapRenderer.COORD_SCALE is initialized properly before any of all those classes, so they use the new calculated scale (if any).
It's the exact same process like Tile.SIZE, which works nicely all this time.

Also those variables can be overridden via Parameters and user sets its own before library initialization.

[devemux86]

Calculation was added on Android: regular + libGDX implementations.
iOS could use probably common dpi check and scale factor.

Desktop or Browser may need another check, due to different dpi / resolution.

[Gustl22]

Sorry my bad! I thought it was added to all environments. I changed the values in calculateCoordScale() and wondered why they weren't updated in the constants.... on Desktop.

Can we add this to Desktop, too, with lower dpi values?

[devemux86]

Sure, I don't have a 4K screen (or similar) available to test now, do we need to use also dpi there and which threshold?

[Gustl22]

Ok I made various tests, always with Viewport.MAX_TILT = 80 and regular PathLayer.

• Desktop 1920 × 1080, unknown ppi/dpi , COORD_SCALE = 8: works fine (minimal clipped)

• Desktop 3840 × 2160, 157 ppi, 96 dpi (software), COORD_SCALE = 8: clipped (see above)

• Android (Smartphone) 1920 × 1080, 432 ppi, 480 dpi, COORD_SCALE = 4: works fine

• Android (Tablet 4:3) 2048 × 1536, 264 ppi, 320 dpi, COORD_SCALE = 8: clipped
  

Desktop does not provide (the right) software density information, cause screen density couldn't be read by system (so always set to 96). So we have to fall back to screen resolution.

My Android Tablet clips the paths: although it has a very high resolution, the density isn't reached.

So I would propose to make all dependent of screen resolution (or a mixture of both) as this defines the range for later OpenGL calculations. As limit we can use dimensions equals and above 1920 × 1080 pixels for COORD_SCALE = 4.0f.

[devemux86]

Note that tilt 80 is not default and we're talking here about default values.
Or else each user can change tilt limits and scale value as wish according to specific needs.

We just need sane defaults testing with inside default settings.

[devemux86]

BTW I tested on an Nexus 9 with above specs and didn't see something strange with default settings.

[devemux86]

So you think the threshold could be if smaller dimension is over 1080px?

[Gustl22]

That sounds good.

For current 65 degree I can't see any issues (with all devices).

[devemux86]

I pushed new implementation for Android and globally for all libGDX based platforms.

[Gustl22]

Works nice! I noticed some clipping on my Phone (1080 width) with higher tilt, but I think we cannot cover all cases and certainly it's customizable, so it's fine! Thanks :)