-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multithreaded Rendering: rendering errors #591
Comments
With c16993b I have just pushed a fix for this. The problem is that the LabelCache was not synchronized properly and that also tiles that were in the process of being rendered were not taken into account for the label boundary overlap calculations. With a threaded TileStore there is still a window for this to happen. As with a multi-threaded renderer the TileStore does not need threading anymore, this should be removed, closing this window. With that done it will also be possible to simplify the synchronization with the LabelCache a bit. |
With ff0ca39 I pushed a fix for a NPE happening with |
About the multi-threaded renderer so far the tests work fine (threaded cache off). I have seen once some rendering artifacts that went away when I reloaded the map. |
And the exception from the app crash: Caught a RuntimeException from the binder stub implementation.java.lang.NullPointerException
at android.inputmethodservice.IInputMethodWrapper.setSessionEnabled(IInputMethodWrapper.java:280)
at com.android.internal.view.IInputMethod$Stub.onTransact(IInputMethod.java:129)
at android.os.Binder.execTransact(Binder.java:404)
at dalvik.system.NativeStart.run(Native Method) |
I think we are hitting two things here: |
Is there any trick to reproduce the problem? I cannot get it to paint the tiles incorrectly. |
It happens in Android and Java with consecutive zooms and pans in a row. For Android I have tried also in Genymotion and see it there too. |
I cannot really reproduce this, but my understanding is that the ill-painted tiles are actually zoom-up tiles from lower zoom levels that should be replaced by the right zoom level once the tiles have been produced. So, it looks like some tiles are never produced. In 104713b I have put a timeout on the wait and added a missing notify call. |
😟 |
Ludwig I don't see any new commit. |
It is there now. I could not push for a while, timeout after timeout, and then I decided to Ludwig On 29 March 2015 at 16:08, Emux notifications@github.com wrote:
|
That is again a tile from a lower zoom level blown up to fit the space I only have two devices with me at the moment, running 5.0 and 5.1, maybe I will probably try to put some debugging messages into dev later, maybe On 30 March 2015 at 05:26, Emux notifications@github.com wrote:
|
No the cache is already altered at that point (none panning or zoom fixes that tile). The exact same behavior happens also in Java. |
Can you confirm that tile really is in the file system tile cache? Because this is never a tile that we would render that way, blurry and all. My suspicion is that for some reason the tile never gets written to the TileBitmap bitmap = this.tileCache.getImmediately(job); if (bitmap == null) { Ludwig On 30 March 2015 at 09:34, Emux notifications@github.com wrote:
|
I just tried in Android 2.3 and after drawing 3-4 tiles we have immediate OOM crashes: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:477)
at org.mapsforge.map.android.graphics.AndroidBitmap.createAndroidBitmap(AndroidBitmap.java:55)
at org.mapsforge.map.android.graphics.AndroidTileBitmap.<init>(AndroidTileBitmap.java:142)
at org.mapsforge.map.android.graphics.AndroidGraphicFactory.createTileBitmap(AndroidGraphicFactory.java:233)
at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:144)
at org.mapsforge.map.layer.renderer.MapWorkerPool$MapWorker.run(MapWorkerPool.java:111)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1088)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:581)
at java.lang.Thread.run(Thread.java:1019) |
The crash is most likely to having too many threads retrieving data at the Interesting to see that that tile really ends up in the cache, currently I Ludwig On 31 March 2015 at 10:13, Emux notifications@github.com wrote:
|
I think I have an explantation for what is happening now, but not yet a solution. The wrong tiles that we see are not zoomed-up versions from lower levels, that was a wrong hunch. The problem lies in the rendertheme matching somewhere. The tiles that are drawn incorrectly are drawn with rendertheme instructions that match a different zoom level from the one that is actually shown. That is why we see this mismatch, which I have now managed to recreate, at zoom levels where there is a change in the render theme instructions for the levels involved. It looks like something is not quite thread-safe at this point: I assume the wrong tiles are already scheduled, then the zoom level changes, but the zoom level for matching stays at the previous level. Some progress, but not quite a solution yet. |
The problem with the tiles are the text and line width scaling that is zoom level specific, but only applied once to each render instruction. When changing the zoom level the scale factors change, which affects all tiles that are being drawn at the time. So, that is why with zoom level changes we get tiles that appear half drawn and some that are drawn thicker than others. Fixing this is not trivial as it requires storing more information per render instruction, as we need to keep the information around for each zoom level. I made an attempt to store the render theme instructions properly scaled for each zoom level, but that uses so much memory that it is not an option. Equally, it is not an option to apply the scaling factors only at drawing time, as the correct size information is already needed at layout time (label clashes). Again, some progress, but not quite a solution yet. |
Thanks for the feedback Ludwig. You mean the RenderContext.setScaleStrokeWidth(zoomLevel) ? |
Yes, strokes and text sizes are scaled per zoom level, but this is not thread safe. I have now a working solution (I hope), but I will need a bit more testing and cleanup. Will hopefull push fix tomorrow. |
With 3d4c465 I pushed a NPE fix. I studied the changes, I'm a bit hesitant for the paints recreation during the map lifetime. |
By the way, we still have OOM errors. |
On 2 April 2015 at 05:59, Emux notifications@github.com wrote:
I studied the changes, I'm a bit hesitant for the paints recreation during
Yes, that is obviously not ideal. With ce48908 it again introduces a We have some drawing issues, like the thick black lines (screenshot): I have now seen this. I have, at this point, not again tried to recreate Ludwig |
👍 About the black lines, I still see them. |
With ef7dad6 I have pushed a fix for the black line problem. Black lines sometimes appeared where lines had a bitmap shader defined (e.g. private access roads with a hatched pattern). The problem was that access to a bitmap shader was not synchronized. This should now be fixed. |
I see strange things with the rendering (we need thorough testing). The same tile in file cache appears different in 2 platforms, in Java it has transparencies. |
Ok the above behavior happens because in SwingMapViewer we create the Nevertheless it's something to check. |
Where are we with this? I understand that the rendering issues regarding the Swing MapViewer are caused by the transparency, is this something that still needs to be addressed? I am internally testing the threaded rendering, so far I do not see any issues, but this is one device only. |
The transparency issue exists and I think we should check it eventually, the optical result for the end user is certainly not good. About the multithreaded rendering I find it currently unusable because of the continuous crashes. |
What happens if you set the thread number to 1? I would be interested if (Obviously, there are more resources required to process two tiles at once, On 8 April 2015 at 03:06, Emux notifications@github.com wrote:
|
Sorry for not mentioning it earlier.. Actually I currently use dev branch with thread number to 1. So far I have not seen any issues with 1 thread. |
I think the problem is that we are sailing so close to the memory limit The problem with the map reader interface is that we
This is a fundamental flaw in the design of the interaction, which has, in
On 9 April 2015 at 03:12, Emux notifications@github.com wrote:
|
After latest fixes do we have any remaining issues, i.e. can multithreading be enabled? |
I think multi-threading will still suffer from the memory problem: too much On 3 September 2016 at 20:37, Emux notifications@github.com wrote:
|
I pushed on Samples use of processors number +1 for multithreaded rendering. |
After fix in #806 and working lately with multiple threads, I have not seen any rendering issues. |
The new multi-threaded renderer does not play well with labels/icons across tile borders.
For the original discussion see:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mapsforge-dev/x19w0iPealM/K3SgbhwdcowJ
The text was updated successfully, but these errors were encountered: