TileLoader not issuing MapRenderer Updates

[braandl]

When using a "Rerender when dirty" Renderingmode, e.g. with libGDX on Android,
ansychronously downloaded maptiles might not be rendered until user interaction.

This is because the TileRenderer waits for a GL Update in order to revalidate the Stat eof the Tiles. (

vtm/vtm/src/org/oscim/layers/tile/TileRenderer.java

Line 83 in d5543bd

public synchronized void update(GLViewport v) {

)

This could be solved by either forcing the map to update until all visible tiles are loaded, or restarting the redraw when a tile gets ready, but would be a little more complex to implement. Usually the first process should not be to heavy, since Tile updates usually follow map movement or viewport changes.

What do you think?

[devemux86]

Testing GdxActivity (e.g. with Mapilion) or vtm-playground samples,
there do not seem to be any problems.

There must be something that can be easily reproduced by everyone to understand the report.

[braandl]

Yep, this is because the libGDX is re-rendering the secene in every case in the current setup.
Which is dramatically inefficient.

I'll provide a branch once I have the sources together. Mine has to many different changes you don't want, so I'll need to make a fresh one.

[devemux86]

VTM core is the base of all backends.
We cannot change the core for only 1 backend (with limited use), affecting all others.

If specifically GDX has any issue, this must be first proved and then solved in its backend.

However the GDX backend is not required on Android.
vtm-android provides much better integration and performance.

[braandl]

Ok, then nevermind. Even tough the performance claim is not entirely true... when you don't use any gdx features it almost adds no overhead, at least not benchmarkable.

gdx would in the end, allow to purge the nasty opengl handwritten code from the layers, providing gdx versions of it, that then would allow may nice and new features like global illumination and shadows.
allso apple is goint to cease opengl support, so you will lose the ios platform in the core. This is probably not going to happen very soon but with the m1 they did another step forward to this.

[devemux86]

vtm-android-gdx was a proof of concept. It is far behind vtm-android in all aspects.

VTM is a map library which must do the basics well.
Not a game framework like GDX, so lights, horizons, shadows have never been a top priority.

And vtm-ios is not maintained by community anyway...

[braandl]

Ok, that's fine for me. Just wanted to help making this nice lib futureproof

[devemux86]

To make it future proof it needs to work with Vulkan,
keeping its stability, compatibility and performance.

[braandl]

Yes, and therefore it should be rebased onto a 3d engine instead of having the same spaghetti implementation in Vulkan as it has right now in OpenGL. And why not chose the obvious choice? Also the vast majority of other engines is to large for mobile apps that just want a map in it. I know that gdx does not have Vulkan support yet, but once apple is really moving forward with the OpenGL removal, I guess it will gain traction. Also gdx has a good license compared to commercial alternatives.

[demiantres]

I came across this problem too. I solved it by using a render loop which checks if the map is dirty instead of requesting to re-render the map each time something changes.

[braandl]

Yes, you can totally do that, but I assume you want the map to not be rerendered without animation or user-interaction because looping the renderer really drains the battery on the device. At least for my usecase that is a nogo. In the end the glsurfaceview on android "knows" when to rerender and you can totally base the mechanism on this and then just add some "awakening" logic for animations.

[demiantres]

With "loop" I meant an interval timer which triggers every 30ms or so and checks for a boolean "isDirty()". As an extension you could start the timer only when the map gets dirty and goes to sleep when the map is clean again. I have not compared the power consumption of the different approaches but I doubt that there is a huge difference.

The CPU/GPU usage is better with the timer approach especially when having multiple layers.

[braandl]

You mean better than letting the GLSurfaceView define the framerate? I have not compared this, but it sounds unlikely.

[demiantres]

Exactly. The GLSurface is bombarded with update calls which could be rendered in one run.

[braandl]

But you would want to allow rerendering in the natural display refresh rate if possible. It should be easy to also make the gdx map only rerender on update events such as loaders did finish, user inputs or animations. And then no scene redraws at all when nothing happens.