ofTexture vs. ofImage regarding auto release in Android


I scanned the code. I saw that ofImage automatically handles unloadGL and reloadGL in android and that nothing needs to be done when using this class, am I reading it right?

Regarding ofTexture. I haven’t seen any handling, is that also correct? Are users of ofTexture expected to implement unloadTextures/reloadTextures themselves in the ofApp and clear/reload their textures as needed?



ofImage stores the pixels in ram so when android deletes the GL context it has the original info to upload it again when the app is resumed but ofTexture only lives in the gpu memory so there’s no way to know what was in it after the context is destroyed and the user will need to recreate it on the reloadGL event.

same happens with ofVbo vs ofVboMesh, where ofVboMesh will restore itself but not ofVbo for the same reason

Thanks for the info, @arturo. I’m still trying to decipher the errors and crashes I’m getting (shown here) related to releasing unknown texture ID. I noticed three weird things in this regard:

  1. I noticed that other than my example texture, TWO textures are being created, but I don’t know where from. They are definitely not members of the ofApp class. They are also not being allocated, just created.

I also noticed that the texture IDs for my textures are correct (first one is 1, second is 2, etc.) but on these mysterious ghost textures, the ID is garbled, for example: 1049007696.

I’m not sure where’s the junk coming from since ofTextureData initialized textureID to 0. I think it’s a bad memory access of some sort that causes the errors and crashes.

  1. I followed the events from unloadGL and reloadGL as I suspect they are part of the issue and I noticed something. Why are the textures being released on unloadGL? It is called due to surfaceDestroyed, and when this method is called, the context is no longer valid and we should not be able to release anything. Further more, as I understand from google’s documentation, we don’t need to release anything on destroy, just recreate everything we need when on surface created is called. I tried removing the texture clearing part, and indeed it seems that this part is unneeded, but I’m still getting crashes. Sometimes it’s in setup, sometimes it’s in onPause. I suspect a memory issue caused by that ghost textures which are no longer valid.

    07-19 17:19:00.421: A/libc(18930): invalid address or address of corrupt block 0xb8363a50 passed to dlfree
    07-19 17:19:00.421: A/libc(18930): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdeadbaad in tid 19300 (GLThread 7375)

I scanned the code to try to find those two textures but came out empty. Can anyone shed some light on this?

  1. in ofTexture, there are methods specific to Android that doesn’t seem to be connected to anything. allTextures() and the register/unregister. Is this some old legacy code that was left there? Or is it still in use and I just haven’t found how it is connected?


Got it. The problem was in ofBitmapFont, in the destructor. Instead of unregistering an event, it registers a different event, and that causes code to run on an unallocated values. Sometimes on junk, sometimes it crashes. Affects only Android. I included this fix, and many more fixes in my PR that improves Android life cycle: https://github.com/openframeworks/openFrameworks/pull/4260

How will this restoration happen? I see that ofImage is registered to both unloadGL and reloadGL, but ofVboMesh is only registered to unload. What will cause it to reload itself?

when the vbo is cleared in the next draw vbomesh will check for vbo.isAllocated() and since it’s not it’ll reallocate it and upload the data as it does when it’s drawn for the first time