Hi.. thanks for the insight. I actually considered the same case and implemented and override for the surfaceDestroyed method of the GLSurfaceView, just to see if it was being destroyed.
Sure enough, the gl surface is destroyed when I "flip" it out of view with the ViewFlipper. That's fine, as I can assume that the textures are destroyed automatically, but just out of curiosity I disabled the view flipper to prevent the surface destruction, and even when the surface is not destroyed I still can't seem to delete textures. I am 100% sure that it is the Renderer thread creating, and destroying the textures, however clearly this is NOT the thread that owns the GL context. I also tried executing the texture delete from within the activity thread (via a queued message), but same problem. I'm at a bit of a loss because they are the only two threads that I create.. but I got side-tracked on some unexpected crashes in native land (which may or may not be related (http://groups.google.com/group/ android-developers/browse_thread/thread/d7967cc89fe6c9cd#)) so I am staying with the "destroy the entire surface" approach for now. Not ideal, but works and I need to move onto other things so it'll have to do. I'd love to understand this more as I hate to use these sort of work-arounds just because I can't solve the underlying problem.. but too much to do... Thanks again. On Aug 24, 6:51 pm, jojoma <thanat...@gmail.com> wrote: > are you changing between the activity that uses your surface and > another one by any chance? because if you are, you're losing the EGL > context in which are kept the names/id's of the currently loaded > textures. By losing that context all this information simply > disappears, without a damn warning... took a while for me to realize > this. Anyways, if you try to delete something that does not exist > anymore, it gives some pretty unknown errors :| > > you can check what I was talking about > here:http://developer.android.com/reference/android/opengl/GLSurfaceView.R... > > On Aug 24, 5:48 am, Jason <jason.poli...@gmail.com> wrote: > > > > > ok.. I may have worked this one out. > > > I added an implementation of the surfaceDestroyed method in the > > GLSurfaceView and just printed a log. > > > It seems the surface is being destroyed at some point before I attempt > > to delete the textures. I can only assume it's the ViewFlipper > > causing the gl surface to be destroyed when I flip to the loading > > screen. > > > In this case, I'm also assuming vram will be cleared, however it does > > mean I can't have textures persisting across levels (which would be > > ideal). > > > Still hoping someone out there has some further insight, but for now > > I'm just removing the code to delete textures. > > > On Aug 24, 12:36 pm, Jason <jason.poli...@gmail.com> wrote: > > > > Hi folks, > > > > I'm trying to get my head around how the vram is used in opengl, > > > specifically when and how to clean it up. > > > > The Story So Far... > > > > I have a GLSurfaceView into which I set a Renderer implementation > > > (called OpenGLRenderThread). > > > > This view is created (manually, by calling "new") in the main Activity > > > of the app. > > > > When the onSurfaceCreated method of the OpenGLRenderThread is called, > > > I load a bunch of textures in a fairly standard way: > > > > ... > > > gl.glGenTextures(mTextureHash.size(), mTextureNameWorkspace, 0); // > > > mTextureHash is just a pseudo hashmap of texture structs, > > > mTextureNameWorkspace is an int array > > > ... > > > // Then... > > > int textureName = mTextureNameWorkspace[textureIndex]; // textureIndex > > > is just an index into the mTextureNameWorkspace array > > > gl.glBindTexture(GL10.GL_TEXTURE_2D, textureName); > > > > The app runs fine, however when I try to clean up these textures at > > > the end of the "level" (the app is a game).. I do the following: > > > > mTextureNameWorkspace[0] = texture.openGLName; // openGLName is the > > > int reference (textureName) obtained from the previous call to > > > glGenTextures > > > gl.glDeleteTextures(1, mTextureNameWorkspace, 0); > > > > On the emulator it works fine, but on the device (HTC Desire, 2.1) I > > > get a GL Error 5572216 > > > > I have no idea what this error code is as I can't seem to find any > > > reference to it. > > > > Now.. I understand that the VRAM references are bound to the thread > > > that created them. Hence they can only be destroyed by the same > > > thread. In my case, this thread is the OpenGLRenderThread (Renderer) > > > during the onSurfaceCreated call. Unfortunately the Renderer > > > interface does not expose an "onSurfaceLost" method, so I created my > > > own. > > > > When the Level is complete, my main activity queues a request on the > > > OpenGLRenderThread using the following call to the GLSurfaceView: > > > > queueEvent(new Runnable() { > > > public void run() { > > > // Reset the texture library > > > onSurfaceLost(); > > > } > > > }); > > > > According to javadoc for queueEvent: > > > > "Queue a runnable to be run on the GL rendering thread" > > > > Ok fine, so this should mean that the OpenGLRenderThread is > > > performing the call to onSurfaceLost. This method is the one that > > > then calls glDeleteTextures, and produces the error. > > > > So.. what am I doing wrong here? I am not destroying the > > > OpenGLRenderThread or the GLSurfaceView at any point (other than game > > > exit) so I'm worried that if I don't explicitly delete the textures my > > > vram will eventually fill up, or worse get into a corrupt state. > > > > The only other thing that may be relevant is the use of a > > > ViewFlipper. Because I want to load each level asynchronously I am > > > using a ViewFlipper in the main activity to flip to a loading screen > > > while all the level resources are rebuilt. Hence when the call to > > > glDeleteTextures is made, the GLSurfaceView is not actually visible... > > > not sure if this is meaningful or not. > > > > Anyone got any bright ideas here? > > > > Thanks! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
