How to improve rendering speed in 0.5.1?

[lele]

Hi I'm testing version 0.5.1.

I noticed big slow-downs when you zoom the map out for the first time. I'm testing it around Milan, Italy and then zooming out. That plus in details from the Alps and such and you clearly see the tiles coming up one by one. It takes several seconds to render the full screen.

After the first zoom-out it seems to keep it in cache and it is a lot faster.

I'm using a brand new Nexus 9, full resolution. The CPU/GPU are quite fast so didn't expect sluggish performance with that.

Is it perhaps that it is trying to render for each pixel? I'm be fine with a 1024x768 for the whole terrain if that speeds things up. Is that a possibility?

I also tried to switch off the hardware acceleration. I expected a big performance hit but it wasn't really that much different

I also tried with an external XML rendered and turning off a lot of features and POI but surprisingly it made very little difference, can somebody explain why?

Is the map loading from disk the main bottleneck perhaps? Can we prefetch it somehow? 

thanks

[Emux]

The map rendering is performed live by processing the vector data on the way (that's the essence of a vector library).
Of course its quite different from getting ready tiles from the file system as raster libraries.

Rendering is accomplished by producing bitmap tiles that appear on screen with variable size per screen depending on device dpi (using 256 as base).

For the tests it's important what maps are in use and which render themes.
It's not difficult to slow things down if we put in a map / render theme a lot of elements (particularly heavy ones) to appear all together in small zoom levels, e.g. show a whole city region with everything on.

The HA is advised to be off because of some rendering issues we had in the past.

The cache can be persistent or not (user's choice).
But it has to be cleared with any map model changes (e.g. new render theme).

In dev branch there are trials to make map rendering multi-threaded (but we have seen issues right now).

--
Emux
Cruiser - Atlas

[lele]

Thanks for the clarification Emux. Just wanted top follow up with some questions

• how do I make the cache persistent?
  
• Why doesn't the map render faster if I remove lots of stuff tom XML render file? I removed terrain, cities and water and it was pretty much as slow. That was a bit counter intuitive to me
• Can I use a different dpi? I really don't need "retina" resolution. I'd much rather have speed.
• Do you have a render theme you recommend for speed?
• Is the dev branch worth a shot or is it too buggy?

By the way I turned HA on and didn't see any issue on my device. Hope this helps.

As always thanks a lot for the help and the incredibly quick response time!!

cheers

[Emux]

On 01/04/2015 03:13 μμ, lele wrote:

Thanks for the clarification Emux. Just wanted top follow up with some questions

Well we try to put examples with all new features in Samples.

• how do I make the cache persistent?
  

The cache persistence need to be defined on its creation, see here.

• Why doesn't the map render faster if I remove lots of stuff tom XML render file? I removed terrain, cities and water and it was pretty much as slow. That was a bit counter intuitive to me

It's a bit generic as written (what map / render theme and where x,y,z)..
It can depend on the type of data, i.e. polygons are slower to render than points.

Also if you're making your own maps it's important what options you're using at map-writer.
e.g. zoom-interval-conf changes can significantly alter map behavior if base zoom levels are set far away

• Can I use a different dpi? I really don't need "retina" resolution. I'd much rather have speed.

You can play with the tile size (though generally not recommended).
There have been several tests in order to define current default implementation.

i.e. it's not optimal to have a fixed tile size of 256 for HD+ screens, everything appears small (like in raster maps) and rendering suffers.
So now the tile size is derived from device and is larger on high dpi screens, so everything draws larger to deal with it.

But of course you can change it, you need to play with the DisplayModel class.
See an example here.

• Do you have a render theme you recommend for speed?

For speed I prefer the included Osmarender theme.

• Is the dev branch worth a shot or is it too buggy?

It's certainly not for production (only for testing purposes).
And there are times that works fine as is and times that needs modifications for playing (like now that threads don't work correctly).

[Emux]

On 01/04/2015 03:13 μμ, lele wrote:

• Is the dev branch worth a shot or is it too buggy?

It's worth mentioning that all new features are first implemented / tested in dev branch.
We also integrate there any submitted PR from users.

So it's beneficial to try it and report any feedback you can.
Its changelog can be seen here.

[lele]

OK, some feedback here. I couldn't understand the slow down in the rendering at high zoom despite playing with details in the map so I removed all maps and only kept the world map (3MB) [world.map]. 

I figured there is no way I would see any slowdowns with that map with a Nexus 9. Very few polygons and a pretty fast CPU/GPU.

To my surprise, however, the sluggishness is still there. Can you please try to replicate that? Just keep zooming out until you are at world-level. Eventually there is a big delay, with tiles coming in almost one by one. 

I'm using the latest dev version which should be multithreaded. Same issue with the non-dev version 0.5.1

Hopefully this will shed some light on the issue because such a powerful GPU can't possibly be sluggish in rendering such few polygons and tiles. There must be a bottleneck somewhere else?

let me know if you need more info

thanks

[Emux]

For the record, I see that behavior too in far stronger devices than N9.

But you need to understand how base zoom levels (defined at map-writer via zoom-interval-conf) work in Mapsforge.

The map file is divided in sub-files, one per base zoom level where the base rendering (and simplification) takes place.

So with the default zoom-interval-conf, in zoom level 0 or 1 we render the world (even simplified) land polygons that are destined for base zoom level 5 (it's quite a distance).

[lele]

Thanks. 

So we have cases in which we have few tiles in the world map (16 or so) each of which takes long to render but they don't really change, since any change would be at a zoom level that is not displayed anyway.

Am I right to assume that implementing a persistent cache would solve all issues?

If yes, what's the best way do di it?

This seems to be ok with the docs (threaded, queue size 10 and persistent) but AndroidStudio marks it as an error. Not sure why.

static TileCache

createTileCache (Context c, String id, int tileSize, float screenRatio, double overdraw, boolean threaded, int queueSize, boolean persistent)

       this.tileCache=AndroidUtil.createTileCache(this, "mapcache",

                this.mapView.getModel().displayModel.getTileSize(), 1.0f,

                this.mapView.getModel().frameBufferModel.getOverdrawFactor(),

                true, 10, true);

Alternatively there is a method

static TileCache

createExternalStorageTileCache (Context c, String id, int firstLevelSize, int tileSize, boolean threaded, int queueSize, boolean persistent)

Which one to use to have a cache on disk? I might have misunderstood the word "persistent" here but the second one seems what I need?

Also, do I want a threaded cache and what queue depth? Can you perhaps write a line as an example for that?

thanks

[Emux]

On 02/04/2015 07:51 μμ, lele wrote:

So we have cases in which we have few tiles in the world map (16 or so) each of which takes long to render but they don't really change, since any change would be at a zoom level that is not displayed anyway.

The default zoom-interval-conf is recommended for most of uses.

But there are cases where we may have to change it (world map may be one of them).

(One example certainly I remember from my maps is if we want semi-transparent polygons)

Am I right to assume that implementing a persistent cache would solve all issues?

The 1st render is performed always live, the next ones come ready from the file cache.

Which one to use to have a cache on disk? I might have misunderstood the word "persistent" here but the second one seems what I need?

The proper call can be seen here.
e.g.
AndroidUtil.createTileCache(this, "mapcache", this.mapView.getModel().displayModel.getTileSize(),
1.0f, this.mapView.getModel().frameBufferModel.getOverdrawFactor(), false, 0, true);

Also, do I want a threaded cache and what queue depth? Can you perhaps write a line as an example for that?

We discontinue threaded cache in favor of multi-threaded rendering, so it wouldn't exist in the future.

[lele]

I tried that as well. I copied and pasted your line but it doesn't seem to work, does it work with you? Using 0.5.1-DEV

Error:(715, 37) error: no suitable method found for createTileCache(APP,String,int,float,double,boolean,int,boolean)

method AndroidUtil.createTileCache(Context,String,int,float,double,boolean) is not applicable

(actual and formal argument lists differ in length)

method AndroidUtil.createTileCache(Context,String,int,float,double) is not applicable

(actual and formal argument lists differ in length)

method AndroidUtil.createTileCache(Context,String,int,int,int,double,boolean) is not applicable

(actual and formal argument lists differ in length)

method AndroidUtil.createTileCache(Context,String,int,int,int,double) is not applicable

(actual and formal argument lists differ in length)

[Emux]

The API has changed in dev (see here for the proper call).

(But it's worth saying that with dev you must be prepared for some instability)