Problems with seemless SVG patterns

[Tobias]

As I try to make my themes completely scalable I converted all patterns to SVG.
I only use sizes like 8/16/32/64/128, those scale well with standard mapsforge at every ppi, as standard uses multiples of 64 for scaling. For Locus I add the "dp" unit.

Most of the patterns are seemless and work well with Locus at 160/320ppi. But with odd multiplicators like 240/480ppi they don't work anymore, see attached screenshots of 240/320ppi.

Same problem applies to Locus internal seems, when SVG patterns are used.

How exactly does "dp" work, and is there a possibility to have seemless SVG patterns that scale with screen density?


Edit - theme for testing is here: http://www.openandromaps.org/wp-content/users/tobias/Elevate4_Locus.zip

[SwissPoPo]

I assume use Locus the same fixed tile size of 512 as mapsforge (I'm not sure if it is 512). Use this formula to see whether it fits an integer in the tile.  <tilesize>/(<Patternsize>*<AndroidSacleFactor>)
With your pattern sizes you only get integers with Scale Factors 1, 2, 4 (160/320/640dpi), not with 0.75, 1.5, 3 (120/240/480dpi). You already know this thread: https://groups.google.com/d/msg/mapsforge-dev/s7OcnFseBTI/CchcWloQjNIJ
Mapsforge does adjust the pattern size to fit in the tile size. It seems Locus has not implemented this feature.

[Tobias]

I think Locus uses a tile size of 256 for all densities.
If you're right about your theory how scaling works there is no possibility to have one SVG size that fits all scale factors, if background SVGs are scaled with odd factors. It would really make sense to use only full integers here.

I tried my luck with fixed sizes so that at least this would be a workaround. There also seems no difference between adding "dp" or not to the value, the SVG is scaled either way. So there seems no possibility to use  SVGs for background patterns. Edit: There is one possibility, just add "px" instead of "dp". Normally in mapsforge no unit means px, so I didn't try this before.

Maybe I'm missing something here, but the documentation is a bit scarce about this.

[Menion]

Hello Tobias,

after loong fight (4 devices, 3 emu), I finally found one emulator with this DPI (change of DPI over ADB were not working correctly). So let's do something with this.

Test sample:
line 617: <area symbol-width="64dp" src="file:../ele_res/p_wood-mixed.svg" />

my device with DPI multiplier 2.5, so Locus correctly generates images with 64x2.5 = 160px. They do fit to 256 even a 512 px tiles (size do not matter here).

So, you suggestion is to round this multiplier to whole numbers that multiply 2 to always correctly fit tiles? So 2.5 round to "2", 3.5 round to "2" (maybe up to 4)? Correct? Or any better solution already used in MapsForge?

[Tobias]

Hi Menion,
thanks for testing!

So, you suggestion is to round this multiplier to whole numbers that multiply 2 to always correctly fit tiles? So 2.5 round to "2", 3.5 round to "2" (maybe up to 4)? Correct?

That's the easiest solution, but only fits pattern with a side length of a power of 2.

Or any better solution already used in MapsForge?

I checked this out bit more. At first I thought it works there because tiles are resized by dpi the same way as patterns (e.g. 512px tiles at 320dpi, so 64px patterns get 128px, 768px tiles at 480dpi, 64px get 192px etc.)
But with apps like OruxMaps which use a fixed tile size of 512px no matter what dpi scaling still works perfect, even if pattern side length is not a power of 2, so this is more elegant. The solution is that patterns are scaled without stopping at tile borders, see the attached screenshot with a tile size of 512px and 480 dpi, and a pattern of 64px scaled to 192px. White are pattern borders, black are tile borders.

[Menion]

Good day Tobias,

thanks for a precise description and tests. I investigate how this is done in new MapsForge library and I have to say, very nice idea and system how it's made. Unfortunately it required quite a lot of work in current library (or let's say Version 3 of old MapsForge). I'm currently thinking if it's better to invest time to improving old modified library or do and commit some optimization changes to new version. Both has it's +/-.

For now, I've at least improved DPI scaling, so now values of density used for scaling will be rounded on all devices to 1, 2, 4 values, so if you will use sizes for your images as 8, 16, 32, 64, you will be fine. Unfortunately my device I use for daily use has density that cause no such troubles, but quick test in emulator and it seems to work fine. Ok for now?

Alternative should be to use new system of mapsForge V4 maps + V4 themes, but seems that difference in speed is still quite huge.

[Tobias]

For now, I've at least improved DPI scaling, so now values of density used for scaling will be rounded on all devices to 1, 2, 4 values, so if you will use sizes for your images as 8, 16, 32, 64, you will be fine. Unfortunately my device I use for daily use has density that cause no such troubles, but quick test in emulator and it seems to work fine. Ok for now?

That's fine, thanks for the quick fix. I'm fine with any working solution.

I forget to mention that this should also apply to lines with a pattern, not just areas.

Rounding up or down makes sense for me (e.g. 3->4, 2.5->2) etc., as this helps to read the maps. With those crazy high density devices it's often better to have it larger (my testing device is also not troubled at 320dpi, so I also have to emulate this).

[Menion]

You are welcome.

To keep consistency, this change apply on all values defined with "dp" units in theme.xml file, so no worry.

[Tobias]

To keep consistency, this change apply on all values defined with "dp" units in theme.xml file, so no worry.

So this applies to stroke-width, symbol-size etc. as well?
If yes I think it's better to keep them scaling in the normal way, which works perfect except for patterns with svg/dp.

[Menion]

Hello Tobias, you know best how it should look like. If you want, I may generate a version for you for test. Otherwise probably in Thrisday should be published new version. Because there will be quite a lot of changes, I expected that in two/three days, I'll publish some bugfix version, so there will be at least these two days to test it and fix it if needed. I do not want to do it now, because this task is not so simple (handle differently scale for areas and for paths) and I believe it should not be needed, Thanks

[Tobias]

because this task is not so simple (handle differently scale for areas and for paths)

I was afraid you would say that :-)
No need for hurry and/or special test version, I'll use fixed size patterns until it works with scalable ones.
But I think other themes (and users) will be affected if not only scaling for patterns will change. We'll see.

[Menion]

If you wanna try, since yesterday is on Google Play new Beta version ( if you use it ). Official version will have smaller delay ( Monday probably ).

[Tobias]

Thanks, I'll look into it as soon as I find the time.

[LocusUser#1]

I understand this correctly that I must now do for my 240 DPI device all symbols by a factor of 1.5 greater?

[Menion]

Nono, all symbols that serve as patterns, should just keep it's sizes as 8, 16, 32, 64 dp values, then you will be fine on all densities.