opensciencemap / vtm

a vector-tile map library written in java - running on android, desktop and within the browser
GNU Lesser General Public License v3.0
238 stars 176 forks source link

(vtm-android) Strange video artifacts when using MapView inside a fragment #118

Open dondos opened 10 years ago

dondos commented 10 years ago

I am seeing strange video artifacts if I use MapView inside a fragment. This happens on an Asus Fonepad tablet (intel x86 cpu with powervr SGX 540 graphics). I am using OSciMap4TileSource as a VectorTileLayer plus a BuildingLayer, a LabelLayer and an ItemizedLayer. MapPosition tilt is set at 60. This artifacts appear randomly and don't dissapear until I switch to other fragments. I am using the current git version of vtm.

example_1 example_2 example_3

hjanetzek commented 10 years ago

Have you tried with some other app using glsurfaceview in a fragment? Though I guess this issue is triggered by excessive use of the stencil buffer which I heard does not work well together with powervr tiled rendering pipeline.. just guessing - In VectorTileLoader try with USE_MESH_POLY=true to not use the stencil buffer for drawing and enable GLAdapter.debug to get some more logging

dondos commented 10 years ago

Setting USE_MESH_POLY=true did indeed solved the problem I was having. But now, for some strange reason the Asus's lock screen has artifacts after running the app:
example4 I had also performed some tests with a Samsung Galaxy Tab 2 (which uses the same SGX540 graphic chipset) and it did not exhibit any kind of artifacts. The only strange thing showing up in the logs (in the Asus case) is :

10-30 15:43:30.640: I/dalvikvm(2659): Could not find method android.opengl.GLES20.glGetActiveAttrib, referenced from method org.oscim.android.gl.AndroidGL.getActiveAttrib
10-30 15:43:30.640: W/dalvikvm(2659): VFY: unable to resolve static method 916: Landroid/opengl/GLES20;.glGetActiveAttrib (IILjava/nio/IntBuffer;Ljava/nio/IntBuffer;)Ljava/lang/String;
10-30 15:43:30.640: D/dalvikvm(2659): VFY: replacing opcode 0x71 at 0x0002

The Asus Fonepad is running android 4.1.2 and the Samsung Tab 2 is running android 4.2.2.

hjanetzek commented 10 years ago

did you reboot the device? this driver seems to keep the state of gl contexts not properly separated.. so it might still have some registers holding garbage

dondos commented 10 years ago

Yes, (now) I did. That predictably rectified the problem...

hjanetzek commented 10 years ago

does the lock screen issue still appear after running vtm?

dondos commented 10 years ago

No, the lock screen issue no longer appear after rebooting the tablet. That probably was an isolated incident (and I didn't think about the "reboot the device" fix, sorry). But, having USE_MESH_POLY set to false (in VectorTileLoader) brings me back to the initial problem. Interestingly enough having MapView inside an Activity does not trigger the artifacts problem on the same device. This only happens if the MapView is wrapped into a fragment.
But the fix is easy (USE_MESH_POLY=true) so I'm satisfied. Thanks.

stleusc commented 10 years ago

What are the impacts of USE_MESH_POLY true vs false? Is one faster than the other or is one more reliable?

What would be the impact of having it set to true as default?

hjanetzek commented 10 years ago

@stleusc Using the mesh layer is slightly slower to load (requires tessellation) and uses more memory but should be faster to render. And it does not support pattern textures atm

hjanetzek commented 10 years ago

@dondos could you try the https://github.com/hjanetzek/vtm/commits/viewport-sync branch? It does not wrap the GLSurfaceView inside an additional View. So it might make a difference when the issue is somehow affected by the view inheritance.

dondos commented 10 years ago

This branch looks nice, no artifacts, but it does something strange: every time I add or remove a markeritem to the itemizedlayer, or if I remove or add the itemizedlayer altogether, the marker icon flashes two-three times, like it can't decide if the road segment should be drawn in front or behind the image.