invalidate() flood

[InI4]

My app here has a "near ANR" after app start on Android 4.2.2.

I am researching this for a few days now. I am running out of ideas now.

I have a map view. After first fix, when I press unzoom UI button (i.e. zoom out), the MapView starts repainting at 30 frames per second. This suffices to block main thread (due to an self written overlay). There are no tiles loaded, no invalidates() issued from the app code. The repainting does not stop (overloading map view by my own class, I see a continuous flood of invalidate() calls not issued by any application part)

09-13 07:06:16.729 11955-11955/de.spieleck.app.badgers.debug D/invalidate: invalidate
                                                               java.lang.Exception
                                                                   at de.spieleck.app.badgers.osmdroid.PoleLimitedMapView.invalidate(PoleLimitedMapView.java:93)
                                                                   at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:3190)
                                                                   at android.os.Handler.dispatchMessage(Handler.java:99)
                                                                   at android.os.Looper.loop(Looper.java:137)
                                                                   at android.app.ActivityThread.main(ActivityThread.java:5279)
                                                                   at java.lang.reflect.Method.invokeNative(Native Method)
                                                                   at java.lang.reflect.Method.invoke(Method.java:511)
                                                                   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102)
                                                                   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)
                                                                   at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
                                                                   at dalvik.system.NativeStart.main(Native Method)

The map is frozen then while the non map UI stays responsive. This does not end by itself. Only way to stop it, is a scroll on the map, which is hard to achive, cause map is so busy repainting. There

Once this flooding has been stopped by a scroll, everything is fine and map is working as expected.

Any hint, where this flood of messages might be coming from?

This issue happens in similar ways on 5.2 and 5.4.

[spyhunter99]

Does this happen on the sample app too? might be related to #164

I can't recreate it with the sample app on the "Starter map" example. Do you have the compass visible by chance? Perhaps it's related to #400 or #283

The only thing i'm seeing that unexpected in the logs is this after zoom in/zoom out
09-13 07:14:43.039 19269-20716/org.osmdroid W/Bitmap: Called reconfigure on a bitmap that is in use! This may cause graphical corruption!

[InI4]

I currently lack the time to set up the sample app. I am not using compass. I use MyLocationNewOverlay and a self written overlay for app/game related items on map. The latter overlay might not fully optimal yet, but it easily copes with usual scoll and use load. I've seen abover error message occasionally, need to check, if this is often.

[spyhunter99]

https://play.google.com/store/apps/details?id=org.osmdroid&hl=en

or download the latest release package and install the APK yourself. The sample map has everything in it and it's what we use for qa/testing

[spyhunter99]

So if I can't reproduce it, there isn't much i can do. The osmdroid sample map does not exhibit this behavior which leads me to believe it's probably something in your code. What my location overlay are you using? There could be a test case that we're missing too. In either case, I need more information

[InI4]

Sorry for being not helpful enough. It's all a matter of time. Just to keep you updated: Cursory toying around with v5.4.1 and an 6.0.0 emulator, I could now see this behaviour also on 6.0.0. It only happens on certain zoom out. Zoom in and scroll are immune. The sequence "going wild" contains a mixture of above thread dumps and Choreographer ones:

java.lang.Exception at de.spieleck.app.badgers.osmdroid.PoleLimitedMapView$override.invalidate(PoleLimitedMapView.java:48) at de.spieleck.app.badgers.osmdroid.PoleLimitedMapView$override.access$dispatch(PoleLimitedMapView.java) at de.spieleck.app.badgers.osmdroid.PoleLimitedMapView.invalidate(PoleLimitedMapView.java:0) at android.view.ViewRootImpl$InvalidateOnAnimationRunnable.run(ViewRootImpl.java:5083) at android.view.Choreographer$CallbackRecord.run(Choreographer.java:791) at android.view.Choreographer.doCallbacks(Choreographer.java:591) at android.view.Choreographer.doFrame(Choreographer.java:560) at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:777) at android.os.Handler.handleCallback(Handler.java:725) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:137) at android.app.ActivityThread.main(ActivityThread.java:5279)

Seems like the zoom out animation kind of gets stuck going forever.

[spyhunter99]

might be related to #413

[InI4]

Nothing conclusive, but some intermediate results. I am testing modified (debug code) snapshot builds of osmdroid now.

1. The problem only seems to appear after two consecutive zoom outs.
2. The problem only seems to appear after the two very first consecutive zoom outs of MapView lifetime.
3. Tracing the Choreographer invalidation calls indicates, that such invalidations still come long after the actual animations have ended (a bit like the Choreographer misses that 2nd zoom out is over).

[spyhunter99]

Is it second zoom out triggered before the first ends? it could be a synchronization issue.

Are the zoom out events fired before the map is displayed?

[InI4]

No sync, no action before map is displayed: A working touch sequence here is: "Start App", "Wait for map display", "touch for dynamic zoom buttons", "unzoom", "wait for unzoom to finish", "touch for dynamic zoom buttons", "unzoom" => Freeze. Map can not be scrolled any more, "lock" can be releaved by a double touch, i.e. one zoom in.

[spyhunter99]

Are you using the built in zoom controls?

[InI4]

Yes, the built in zoom controlls.

[spyhunter99]

I'm still having problems reproducing on 6.0 hardware and the emulator. What kind of device is this on? Again, does this happen on the example app or this behavior only in yours?

[InI4]

My App. I have not yet setup the building of the example app. Too many lose ends, to little time. I have the issue here now on an S4Active A4.2.2 on an Android 5X Emulator A6.0 and I have a user report from an Moto G (2nd Gen) A6.0. I have another user report from an Sony device which seems immune.

[spyhunter99]

Can you download the sample app? It's on github under releases or on Google
play

On Sep 20, 2016 1:57 AM, "InI4" notifications@github.com wrote:

My App. I have not yet setup the building of the example app. Too many
lose ends, to little time. I have the issue here now on an S4Active A4.2.2
on an Android 5X Emulator A6.0 and I have a user report from an Moto G (2nd
Gen) A6.0. I have another user report from an Sony device which seems
immune.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#411 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB4kGUa_D3lkWoDXe5xOXTRYorB-9Jjzks5qr3XGgaJpZM4J7TdZ
.

[InI4]

I wasn't aware, the test app was available on Googe Play. I've put it on my "hardcode" A4.2.2 device. I can not reproduce the issue there. On OSMapView with TilesOverlay (wo custom TileSource) zooming in is very much broken: Map is only painted here after you scroll after the zoom. Zooming out however works flawless. I also fail to fail in the Bug Drivers section.

However toying with my own MapController branch, I got my App to behave seemingly better (user reports not complete, data not exactly matching): I moved the statement mMapView.mIsAnimating.set(false); from the middle to the very end of the Method protected void onAnimationEnd(). I do not know, what other side effects that might have. I haven't heard of any so far.

[spyhunter99]

@InI4 well one issue at a time. If you can't reproduce the issue with the sample app, then it's probably something specific with your code.

OSMapView with TilesOverlay (wo custom TileSource),
There are some issues with having more than one tiles overlay and the view not being repainted until after the map is moved.

I also fail to fail in the Bug Drivers section.
I'm assuming you meant, failed to find the Bug Drivers section. Is that correct? It's on the main list, just scroll down.

[InI4]

I apologize I have no deep understanding of the Android View hierarchy. It would obviously help more, if someone looked into it, who understood, what happened. But maybe this points in some direction:

But I introduced some debug code lately in my osmdroid branch: I traced all calls to invalidate(), invalidateDelayed(), postInvalidate() and postInvalidateDelayed() and found no code of my app being called on corresponding traces, That is, my observed endless events seem to be triggered by interaction between MapView.computeScroll() and MapView.setZoomLevel(). Apparently an invalidate can trigger a computeScroll(), can trigger a setZoomLevel() and both can trigger invalidations, in my case occasionally infinite ones.

For now I am going to release my next app test version with the call to setZoomLevel() being removed from computeScroll().

[wolojoli]

It is reproducible with the "Follow me" sample.

[monsieurtanuki]

@InI4 Still happening? Can we close this issue?

[InI4]

@monsieurtanuki I did not observe this behavior with 6.0.2 so far.