www.jpct.net
jPCT-AE - a 3d engine for Android => Bugs => Topic started by: nimo on August 23, 2010, 11:53:25 pm
-
Hi,
first of all, thank you very much for this amazing library for Android.
I noticed a strange behaviour in my 3D application, and I noticed that the same problem is present in your demo downloaded from the site, so you'll be able to verify directly.
To reproduce the problem:
1 - Open the demo application: it works fine
2 - Press the 'Home' button to return to Android home screen
3 - Open again the demo application: now I see only a blank screen ???
In my application, this problem occurs also when pressing the 'back' button.
Same behaviour both on my HTC Desire with Froyo 2.2 and on the Android emulator.
Thank you very much for your support
Paolo
P.S.: Sorry for my bad english (I'm Italian ;D)
-
No, that's no a bug. If you press home or back or a call comes in or a thunder storm approaches, i.e. in almost every situation, either the surface or the whole activity can be paused/stopped/destroyed. Each of these actions destroys the open gl context. The demo doesn't really deal with this (as stated in its docs). It's up to you to handle this case, it's not part of the engine. However, it offers some implicit and explicit help to ease this.
Here's what i'm doing following the suggestions that raft gave me. It might not be perfect...anyway:
- create almost all of your attributes as attributes of the Activity, not of the renderer.
- set Config.glAvoidTextureCopies to false (or as an alternative call keepPixelData(true) on each texture). This will make jPCT upload the proper texture content again after a context change.
- add a static attribute to your Activity to store the Activity itself.
- once the activity has been fully created, store this into that attribute. Watch out that at least Android 2.2 likes to create and destroy the Activity one time before it actually does anything real with it, so don't do this directly in onCreate() but later or otherwise you might store an almost empty Activity.
- in the onCreate(...)-method, check this attribute. If it's not null, use reflection to copy all the context of the stored activity into the newly created one
- design the onSurfaceChanged() and onSurfaceCreated() methods in a way that they don't do unneeded or even harmful reinitialization work when creating a surfaces for the second or the third time. All i do then is to create a new framebuffer. This is mandatory, because the gl instance has changed.
- ...anything else...i'm pretty sure, i just can't remember it. jPCT-AE does some internal things to recover from a context change automatically. You'll notice this from the log when using VBOs for example.
Or another solution that i used in my benchmark application: onPause(), onStop(),...all do a System.exit()...
-
once the activity has been fully created, store this into that attribute. Watch out that at least Android 2.2 likes to create and destroy the Activity one time before it actually does anything real with it, so don't do this directly in onCreate() but later or otherwise you might store an almost empty Activity.
i wasnt aware of this 2.2 thing. but i suppose we can still store our Activity in onCreate() method. for example onCreate() is still a good candidate for loading textures. this way, next call to onCreate() on next instance wont reload textures.
in the onCreate(...)-method, check this attribute. If it's not null, use reflection to copy all the context of the stored activity into the newly created one
is reflection really necessary here ? i copy necessary fields manually.
-
i wasnt aware of this 2.2 thing. but i suppose we can still store our Activity in onCreate() method. for example onCreate() is still a good candidate for loading textures. this way, next call to onCreate() on next instance wont reload textures.
That should work fine too. I don't know if it's common behaviour, but my 2.2. emulator does behave that way.
is reflection really necessary here ? i copy necessary fields manually.
No, of course not. You can copy them manually as well. But using reflection, i don't have to care about adding new fields. And the code is really simple:
private void copy(AlienRunner src) {
try {
Logger.log("Copying data from master Activity!");
Field[] fs = src.getClass().getDeclaredFields();
for (Field f : fs) {
f.setAccessible(true);
f.set(this, f.get(src));
}
} catch (Exception e) {
throw new RuntimeException(e);
}
}
-
What's wrong about this? I can't click the home screen and go back becuase i lose the cube.
public class Liberable extends Activity {
private GLSurfaceView mGLView;
private Renderer renderer = null;
private FrameBuffer fb = null;
private Light sun=null;
private World world = null;
private Object3D cube=null;
private boolean paused = false;
public Liberable _instance;
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if(_instance==null)
{
mGLView = new GLSurfaceView(getApplication());
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
// Ensure that we get a 16bit framebuffer. Otherwise, we'll fall
// back to Pixelflinger on some device (read: Samsung I7500)
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
renderer = new Renderer();
mGLView.setRenderer(renderer);
setContentView(mGLView);
_instance=this;
Log.d("Liberable","0");
}
else
{
Log.d("Liberable","1");
copy(_instance);
renderer.reset();
}
}
@Override
protected void onPause() {
_instance.paused = true;
super.onPause();
mGLView.onPause();
}
@Override
protected void onResume() {
if(_instance.paused)
{
Log.d("Liberable","2");
copy(_instance);
renderer.reset();
}
_instance.paused = false;
super.onResume();
mGLView.onResume();
}
protected void onStop() {
renderer.stop();
super.onStop();
}
private void copy(Liberable src) {
try {
Logger.log("Copying data from master Activity!");
Field[] fs = src.getClass().getDeclaredFields();
for (Field f : fs) {
f.setAccessible(true);
f.set(this, f.get(src));
}
} catch (Exception e) {
throw new RuntimeException(e);
}
}
class Renderer implements GLSurfaceView.Renderer {
private boolean resetFB=false;
private boolean stop = false;
int w;
int h;
public Renderer()
{
Config.glAvoidTextureCopies=false;
}
@Override
public void onDrawFrame(GL10 gl) {
try {
if (!stop) {
if (paused) {
Thread.sleep(500);
} else {
if(resetFB)
{
fb = new FrameBuffer(gl, w, h);
resetFB=false;
}
fb.clear();
world.renderScene(fb);
world.draw(fb);
fb.display();
}
}
else {
if (fb != null) {
fb.dispose();
fb = null;
}
}
} catch (Exception e) {
Logger.log("Drawing thread terminated!", Logger.MESSAGE);
}
}
@Override
public void onSurfaceChanged(GL10 gl, int w, int h) {
if (fb != null) {
fb.dispose();
}
fb = new FrameBuffer(gl, w, h);
Log.d("Pepe", "w:"+w+",h:"+h);
this.h=h;
this.w=w;
Log.d("Liberable","Changed");
}
@Override
public void onSurfaceCreated(GL10 gl, EGLConfig config) {
// if (fb != null) {
// fb.dispose();
// }
// fb = new FrameBuffer(gl, w, h);
Log.d("Liberable","Created");
TextureManager.getInstance().flush();
world = new World();
Resources res = getResources();
TextureManager tm = TextureManager.getInstance();
Texture lineasT=new Texture(res.openRawResource(R.raw.blanco),true);
tm.addTexture("white", lineasT);
cube=Primitives.getCube(3);
cube.setTexture("white");
cube.build();
world.addObject(cube);
sun = new Light(world);
Camera cam = world.getCamera();
cam.moveCamera(Camera.CAMERA_MOVEOUT, 10);
cam.lookAt(cube.getTransformedCenter());
cam.setFOV(1.5f);
sun.setIntensity(250, 250, 250);
SimpleVector sv = new SimpleVector();
sv.set(cube.getTransformedCenter());
sv.y -= 300;
sv.x -= 100;
sv.z += 200;
sun.setPosition(sv);
}
public void stop() {
stop = true;
if (fb != null) {
fb.dispose();
fb = null;
}
}
public void reset()
{
resetFB=true;
}
}
}
-
try making _instance a static field.
private static Liberable _instance;
you want that field survive among Liberable instances but making it non-static does not help that
-
Yes, sorry about that, i'd tried with the static approach before posting and with the same results, then I tried with the non-static approach (just to test) and that's why is posted that way ;D.
Somehow making the _instance attribute static doesn't prevent me from getting a black screen when I return to the view.
-
i see. looking again to your code, i'm not sure you can share renderer this way. when a second Liberable is created setContentView is not called on that instance. that's possibly why you get black screen: if there is no view there is nothing to display.
-
Looking at the Logcat there's no second call to the method onCreate() ???, that's weird...
Edit: It's being called now, but i wonder what view to use to setContenView() because if i try to use the same one I have in the instance I get an exception because the view belong to it's parent,however, i try on the onPause() to remove the view from the parent but the result is the same.
-
I think i wasn't clear on this, but i'm not sharing renderer and view and all that stuff from oncreate(). It might get copied too, but will be replaced afterwards by creating new instances. I.e. u'm doing the copying first, then i'm doing the 'normal' init work of oncreate and i'm doing this each time that the method is being called. If a renderer already exists, i'm stopping it in addition...just to be sure.
-
I solved the problem, but i have to create a new GLSurfaceView instance and set the content with it on the onResume() method for the second time, Don't know if this is the properly approach but it's the only way I've found to do it.
-
I found following solution to resolve same situation. If my JPCT-AE application will be game, I don't really need several instances of my application running (read activities). Thus I made my gl renderer and its data (3d objects, textures etc) static and add check for initialization of data. That helps then it comes to activity start/stop, pause/resume and also to device orientation change (since android restarts activity on orientation change). Hope such approach can help you.
-
I have a similar problem in my Wallpaper.
I was getting intermittent crashes when going in and out of the wallpaper settings. But the wallpaper was still running in the background. Objects would intermittently disappear and reappear.
So as suggested in this thread to re-create the GLViewSurface, I added this to onResume() in my WallpaperService class:
if (renderer != null)
{
renderer.release();
renderer = null;
// New renderer
renderer = new WallpaperRenderer(getApplicationContext());
//setRenderer(renderer); // Causes crash, "setRenderer is already set"
//setRenderMode(RENDERMODE_CONTINUOUSLY);
}
..which basically re-creates my WallpaperRenderer class, which implements GLSurfaceView.Renderer.
Now that actually fixed the problem on my Gingerbread phone completely, but on my HoneyComb tablet I'm now seeing a texture problem.
If I have some other wallpaper running, then go to Settings->Wallpaper->[select my wallpaper], everything is fine.
But if I have my own wallpaper running in the background and then go to Settings->Wallpaper->[select my wallpaper], all textures are missing in the wallpaper preview screen. I still see the objects but they are blank objects with no texture. But if I press "Set Wallpaper", everything is fine and the wallpaper gets all its textures back. Then if I go back into the wallpaper selection screen, I get a crash (see below), but the wallpaper is still running behind the error.
02-01 00:02:23.670: E/AndroidRuntime(13380): FATAL EXCEPTION: GLThread 10
02-01 00:02:23.670: E/AndroidRuntime(13380): java.lang.NullPointerException
02-01 00:02:23.670: E/AndroidRuntime(13380): at com.threed.jpct.World.draw(World.java:1333)
02-01 00:02:23.670: E/AndroidRuntime(13380): at com.threed.jpct.World.draw(World.java:1135)
01-31 23:44:32.060: I/jPCT-AE(13336): Visibility lists disposed!
01-31 23:44:32.060: I/jPCT-AE(13336): All texture data unloaded from gpu!
01-31 23:44:32.060: I/jPCT-AE(13336): Disposing VBOs!
01-31 23:44:32.060: I/jPCT-AE(13336): Renderer disposed!
01-31 23:44:32.060: I/jPCT-AE(13336): Static references cleared...
01-31 23:44:32.060: I/jPCT-AE(13336): OpenGL vendor: NVIDIA Corporation
...and the rest of it..
and then a huge amount of:
01-31 23:44:32.480: I/jPCT-AE(13336): [ 1328013872491 ] - WARNING: OpenGL context has changed...trying to recover...
(I was seeing this earlier as well)
I tried to use temp.keepPixelData(true) on each texture, but that made no difference.
I have a static class that saves the instance of my wallpaper.java class so I'm not reloading all the textures and objects when onSurfaceCreated is called.
I'm using Robert Green's GLWallpaperService btw.
If someone has a working wallpaper using GLWallpaperService, can you please send me the WallpaperService.java file and WallpaperRender.java file?
-
Try to set the Logger to debug mode and post the log output for each individual step. Maybe that helps to find the problem. Which renderer are you using? 1.x or 2.0?
-
I'm using 1.x. It seems that somehow two instances of the wallpaper are causing a conflict. Perhaps jPCT is identifying things based on the package name?
It's getting late here so I'll get onto it tomorrow. cheers.
-
No, it doesn't bind anything to the package name. It identifies the renderer and the gl context based on an id that should be unique. You might want to download this version: http://jpct.de/download/beta/jpct_ae.jar (http://jpct.de/download/beta/jpct_ae.jar)...it has better debug output for this id.
However, the nullpointer that you are getting indicates that the FrameBuffer you are using has no gl context. This can only happen when you are using an instance of FrameBuffer that has been disposed.
-
Ok I'll try that jar later on and post the logs.
The GLWalpaperService stops the OpenGL rendering pump when onPause is called so I don't know why my onDrawFrame function is called while the framebuffer is being re-created. It crashes with the clear framebuffer function as well sometimes so it seems to be a timing issue, but I'm not using multiple threads. Anyway we'll see what the logs tell us.
-
Ok I installed the new Jar and the latest GLWallpaperService and added my own logging when the renderer calls are made.
The attached log is when I have the wallpaper currently running fine in the background, then go into the wallpaper picker and choose my wallpaper again. When the wallpaper appears in the wallpaper picker screen there are no textures and every 3D object is a solid color.
When I click 'Set Wallpaper', the wallpaper is working perfectly again on the homescreen.
[attachment deleted by admin]
-
...but you haven't set the Logger to debug mode, have you?
-
Oops its on Verbose, I'll do it again.
Edit: new log attached. Not much difference though.
[attachment deleted by admin]
-
I've created a test case that loses it's textures when re-choosing the wallpaper as displayed in the attachment.
I'll send the test case to you in a moment. Many thanks for helping, I've spent hours trying to get it reliable.
[attachment deleted by admin]
-
Oops its on Verbose, I'll do it again.
Edit: new log attached. Not much difference though.
This doesn't look right...there's no debug output as far as i can see. Make sure that you did
Logger.setLogLevel(Logger.LL_DEBUG); right at the beginning of your Activity.
-
I see now ok I put it in the wallpaperservice engine contructor. New log file.
I'll send the test case anyway as reference.
[attachment deleted by admin]
-
The log looks actually fine except for one disposal of VisibilityList which i'm not sure of. I'll have a look at the test case later. Does it fail on PowerVR too, because i don't have an NVidia based devices?
-
I tried vigorously to get it to fail on the PowerVR but it's 100% reliable ??? I'm almost certain I've seen that texture problem on the PVR as well. However a lot of code was updated/changed recently so I'm out of ideas.
I'll test it on an Omap Tablet running Honeycomb tomorrow to see if it's an nVidia bug or perhaps a honeycomb bug (Which wouldn't surprise me since Honeycomb to Android is like Vista to Microsoft).
-
Can't reproduce the problem on Nexus S with ICS....but i had a closer look at the log that you send me, and some things are really strange with the output. But at first: This log isn't taken from the beta version that i uploaded...it prints out messages that are long gone while others are missing. So please double check your setup to ensure that you are using the latest version.
Anyway, the log contains two things that puzzles me:
02-01 21:22:43.820: I/jPCT-AE(15360): Visibility lists disposed!
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 1
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 2
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 3
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 4
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 5
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 6
02-01 21:22:43.820: I/jPCT-AE(15360): All texture data unloaded from gpu!
02-01 21:22:43.820: I/jPCT-AE(15360): Disposing VBOs!
02-01 21:22:43.820: I/jPCT-AE(15360): Renderer disposed!
02-01 21:22:43.820: I/jPCT-AE(15360): Static references cleared...
02-01 21:22:43.820: I/jPCT-AE(15360): OpenGL vendor: NVIDIA Corporation
02-01 21:22:43.820: I/jPCT-AE(15360): OpenGL renderer: NVIDIA AP
02-01 21:22:43.820: I/jPCT-AE(15360): OpenGL version: OpenGL ES-CM 1.1
02-01 21:22:43.820: I/jPCT-AE(15360): OpenGL renderer initialized (using 2 texture stages)
....
02-01 21:22:43.910: I/jPCT-AE(15360): Visibility lists disposed!
The first part looks fine...the old framebuffer gets disposed, the new comes up...and then, something disposes a visibility list again. That doesn't make much sense, because if there were multiple lists (which i doubt for this application), they should be disposed one after the other. And not one after creating the new buffer. The other thing is even stranger:
02-01 21:22:43.820: I/jPCT-AE(15360): Visibility lists disposed!
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 1
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 2
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 3
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 4
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 5
02-01 21:22:43.820: I/jPCT-AE(15360): Unloaded texture: 6
02-01 21:22:43.820: I/jPCT-AE(15360): All texture data unloaded from gpu!
02-01 21:22:43.820: I/jPCT-AE(15360): Disposing VBOs!
02-01 21:22:43.820: I/jPCT-AE(15360): Renderer disposed!
02-01 21:22:43.820: I/jPCT-AE(15360): Static references cleared...
02-01 21:22:43.820: I/jPCT-AE(15360): OpenGL vendor: NVIDIA Corporation
02-01 21:22:43.820: I/jPCT-AE(15360): OpenGL renderer: NVIDIA AP
02-01 21:22:43.820: I/jPCT-AE(15360): OpenGL version: OpenGL ES-CM 1.1
02-01 21:22:43.820: I/jPCT-AE(15360): OpenGL renderer initialized (using 2 texture stages)
02-01 21:22:43.820: I/jPCT-AE(15360): Memory usage before compacting: 9503 KB used out of 9607 KB
....
02-01 21:22:43.910: I/jPCT-AE(15360): Visibility lists disposed!
02-01 21:22:43.970: D/dalvikvm(15360): GC_CONCURRENT freed 0K, 5% free 10201K/10695K, paused 4ms+3ms
02-01 21:22:43.970: I/jPCT-AE(15360): New texture's id is: 7
02-01 21:22:43.970: I/jPCT-AE(15360): New texture uploaded: com.threed.jpct.Texture@4069f520 in thread Thread[GLThread 9,5,main]
02-01 21:22:43.970: I/jPCT-AE(15360): [ 1328091763987 ] - WARNING: OpenGL context has changed...trying to recover...
02-01 21:22:43.980: I/jPCT-AE(15360): New texture's id is: 8
02-01 21:22:43.980: I/jPCT-AE(15360): New texture uploaded: com.threed.jpct.Texture@4069a658 in thread Thread[GLThread 9,5,main]
02-01 21:22:43.980: I/jPCT-AE(15360): [ 1328091763994 ] - WARNING: OpenGL context has changed...trying to recover...
02-01 21:22:43.980: I/jPCT-AE(15360): [ 1328091763995 ] - WARNING: OpenGL context has changed...trying to recover...
02-01 21:22:43.980: I/jPCT-AE(15360): Object 'object6' shares VBOs with object 'object5'
02-01 21:22:43.980: I/jPCT-AE(15360): [ 1328091763996 ] - WARNING: OpenGL context has changed...trying to recover...
02-01 21:22:43.980: I/jPCT-AE(15360): Object 'object9' shares VBOs with object 'object5'
02-01 21:22:43.980: I/jPCT-AE(15360): [ 1328091763996 ] - WARNING: OpenGL context has changed...trying to recover...
02-01 21:22:43.980: I/jPCT-AE(15360): Object 'object10' shares VBOs with object 'object5'
02-01 21:22:43.980: I/jPCT-AE(15360): [ 1328091763997 ] - WARNING: OpenGL context has changed...trying to recover...
02-01 21:22:43.980: I/jPCT-AE(15360): Object 'object11' shares VBOs with object 'object5'
02-01 21:22:43.980: I/jPCT-AE(15360): [ 1328091763997 ] - WARNING: OpenGL context has changed...trying to recover...
02-01 21:22:43.980: I/jPCT-AE(15360): Object 'object12' shares VBOs with object 'object5'
...
02-01 21:22:44.320: I/jPCT-AE(15360): Memory usage after compacting: 9099 KB used out of 11335 KB
Focus on the messages from the MemoryHelper: How can this be? How can the MemoryHelper start to compact (which happens in your code after creating the new FrameBuffer, which the log reflects)...but then, a draw-call seems to happen as all data is uploaded to the GPU again and THEN the MemoryHelper finishes it's work. This can only happen if the onDraw-call and the call to onSurfaceChanged happen in different threads. Can it be that onDraw() runs in the old thread but with a new FrameBuffer? So that the engine detects that it should upload the texture again (because of the context change) but it does so in the wrong thread?
This doesn't happen in my tests...everything runs in order as it's supposed to run. I suggest to add two different outputs: In addition to the one that logs the start of a method, also log the end. And also log start and end of onDraw(). In addition, log the actual thread at least in onDraw() and in the onSurface...()-methods. Maybe that will help...
-
I'm calling MemoryHelper.compact() in onSurfaceCreated to accurately measure the memory usage before and after loading the 3D objects, so maybe you are right, the GC may be causing problems in the few milliseconds the frame buffer is disposed and recreated. I'll remove it and see if that solves the problem.
-
No, that's not exactly what i meant...it's not possible for all these "OpenGL context..." messages to appear between the two lines from the MemoryHelper if it doesn't happen in another thread...which it isn't supposed to do. It would be really helpful if you could add the additional logging that i suggested, because then we know...
-
I did a file binary compare of the Jar in the project and the one you posted above, both are identical. Perhaps that Jar above is not the beta?
I'll add those extra logging lines and post the full log.
-
Maybe i've picked some old version by accident...i've uploaded it again. Now it IS the new one... :)
-
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]
-
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:
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 (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.
-
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.
-
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 ::)
-
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]
-
You still have multiple threads working on one FrameBuffer...for example:
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...
-
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.
-
Thanks for persevering through all this.
No problem. Iit helps me to add better debug output after all.