Maybe a bug? Blank screen after Home button pressed

[K24A3]

Attached is the new log with the updated Jar and more logging added and MemHelper removed from onSurfaceChanged.

Log.txt is the full log from start to finish where the textures go missing after re-picking the same wallwaper.

Log2.txt is a short log starting just before the wallpaper was selected and displaying the missing textures.

[attachment deleted by admin]

[EgonOlsen]

You haven't added the output of the actual thread to onDraw and onSurface...(just add a "+ Thread.currentThread()" to the output string)...however, even without that, there's one part that is interesting:

Code Select Expand


02-02 18:46:03.490: I/jPCT-AE(872): New texture's id is: 1
02-02 18:46:03.490: I/jPCT-AE(872): New texture uploaded: com.threed.jpct.Texture@4076c068 in thread Thread[GLThread 18,5,main]
02-02 18:46:03.490: I/jPCT-AE(872): OpenGL context has changed...trying to recover!
02-02 18:46:03.520: D/dalvikvm(872): GC_CONCURRENT freed 258K, 12% free 10253K/11527K, paused 3ms+4ms
02-02 18:46:03.550: D/dalvikvm(872): GC_FOR_ALLOC freed 1024K, 20% free 9229K/11527K, paused 35ms
02-02 18:46:03.550: I/dalvikvm-heap(872): Grow heap (frag case) to 10.130MB for 1048592-byte allocation
02-02 18:46:03.600: D/dalvikvm(872): GC_CONCURRENT freed 5K, 12% free 10248K/11527K, paused 4ms+3ms
02-02 18:46:03.610: I/jPCT-AE(872): New texture's id is: 4
02-02 18:46:03.610: I/jPCT-AE(872): New texture uploaded: com.threed.jpct.Texture@4076c068 in thread Thread[GLThread 17,5,main]


so obviously, it's uploading the same texture (Texture@4076c068) in two threads ([GLThread 18,5,main] and [GLThread 17,5,main]). And actually, this isn't a problem if it would happen in different contexts using different frame buffers. But because your frame buffer will be shared between the threads, this isn't the case. Try to make the FrameBuffer instance thread dependent. Either with a WeakHashMap by using the thread as a key or with a ThreadLocal http://docs.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html. This might solve the actual issue but will cause another one: The geometry is not designed to be displayed in different contexts at a time. It is bound to one and if that changes, you'll get these "recover"-messages. So in this case, you'll most likely end up with a kind of recover-ping-pong. You should try to add some code that skips the actual rendering of the wallpaper on the homescreen if the setup activity is visible. That should prevent the ping-pong from happening.

[EgonOlsen]

Or you can try to disable VBO support in Config. That way, the geometry isn't bound to the context anymore and can skip that disable-drawing-to-prevent-ping-pong part for now. You still have to use different frame buffers per thread.

[K24A3]

Ok that explains a lot, I believe I understand the logic of it all now.

The WallpaperService can have multiple instances of the Engine running, which means I either need to create separate worlds for each instance (too complex, too much RAM usage), or simply keep the world static and pause background rendering so it doesn't play ping pong with the textures. I need to figure out how I can detect when an instance of the Engine is hidden.

Edit: using Engine.isVisible() and isPreview() may help 

[K24A3]

I got the new system working great on the PowerVR. It's 100% stable, individual engines don't draw unless visible, textures and 3D objects are only loaded on the first Engine creation.

But on the Tegra I'm getting texture problems again, but this time it's random textures that are not rendering. Some are ok but others are missing, however most of the time all the textures are working fine. Plus a crash from a null pointer at com.threed.jpct.World.renderScene(World.java:999), and a "WARNING: There's a problem with the object list not being consistent during rendering. This is often caused by concurrent modification of jPCT objects on a thread different from the rendering thread!" which confuses me because I'm only drawing one Engine at any time.

I'll look into the things you mentioned earlier and try to figure it out.
Attached is the log, maybe you can spot the problem easily.

[attachment deleted by admin]

[EgonOlsen]

You still have multiple threads working on one FrameBuffer...for example:

Code Select Expand


02-02 22:30:31.870: I/jPCT-AE(20638): New texture's id is: 1
02-02 22:30:31.870: I/jPCT-AE(20638): New texture uploaded: com.threed.jpct.Texture@40762808 in thread Thread[GLThread 32,5,main]
02-02 22:30:31.870: I/jPCT-AE(20638): Additional visibility list (2) created with size: 512
02-02 22:30:31.930: I/jPCT-AE(20638): New texture's id is: 32
02-02 22:30:31.930: I/jPCT-AE(20638): New texture uploaded: com.threed.jpct.Texture@407068a8 in thread Thread[GLThread 12,5,main]


[GLThread 12,5,main] is the older one from above and [GLThread 32,5,main] the new one, which created the new FrameBuffer. I don't know how you are preventing one of the threads from drawing, but obviously, it doesn't work. At least not in all cases. In addition, even when doing so, i strongly suggest to use one FrameBuffer per thread or otherwise, you are happily mixing contexts with unknown consequences...

[K24A3]

Yeah it struck me as obvious a moment ago :facepalm: .. why would different rendering engines use the same framebuffer?

Moving the framebuffer disposal and creation in the onSurfaceChanged function of each Engine then parsing the framebuffer object down through onDrawFrame() has resolved the problem. It's working 100% on the Tegra now.

Thanks for persevering through all this.

[EgonOlsen]

Thanks for persevering through all this.

No problem. Iit helps me to add better debug output after all.