Memory usage profiling an openGL application?

Problems with Canvas, OpenGL, etc...

Memory usage profiling an openGL application?

Postby 39thstreet » Mon Aug 23, 2010 5:42 pm

I've got an otherwise operational beta Android game which crashes out after a while on my device (Droid X). I'm fairly sure my problem is that my textures are not being properly cleared from memory. I'd like to confirm this fact before I start blindly making changes. My game does fairly frequent level transitions. During these transitions I typically dump a texture file, wait a bit, then load a new one.

Over time the application performance degrades. After 10 or so transitions frame rate starts to take a nose dive. 10 or so more and it usually dies. Prior to dying I see log messages like this:
08-23 12:26:58.038: DEBUG/Cursor(1265): fillWindow is not executed because Cursor object is closed.
08-23 12:27:27.186: INFO/ActivityManager(1239): Low Memory: No more background processes.

And then eventually:
08-23 12:27:46.952: INFO/ActivityManager(1239): Process (pid 4927) has died.

There are no specific error messages of any sort. I've got lots of ideas for things to try to fix this (e,g, glDeleteTextures may not be working), but I really want a way to measure before I start trying to fix.

Any help/pointers would be greatly appreciated, thanks in advance!
Once Poster
Once Poster
Posts: 1
Joined: Mon Aug 23, 2010 5:37 pm


Re: Memory usage profiling an openGL application?

Postby MichaelEGR » Mon Aug 23, 2010 11:02 pm

The way I go about memory profiling right now is taking snapshots (hprof) with the Android debugger (ddms) and run the basic conversion tool on it so that it can be opened by YourKit. You then can compare two memory profile snapshots against each other say before and after a level transition and determine where the leaks and any unreleased resources may reside. I highly recommend YourKit and have been using it for years and years on the desktop and it works great for compare and contrasting memory profile snapshots too. I've been able to solve all resource / memory issues with TyphonRT with this approach. Mind you it's a little tedious since Android doesn't support JVMTI and the profiler tools can't be run during normal execution.

Since it sounds like you are loading a lot of resources you may have to create a LRU (least recently used) cache for textures so that old ones get automatically unloaded when more recent ones are required. This is actually on my fairly short list for TyphonRT.
Founder & Principal Architect; EGR Software LLC
User avatar
Senior Developer
Senior Developer
Posts: 147
Joined: Thu Jan 21, 2010 5:30 am
Location: San Francisco, CA


Return to Android 2D/3D Graphics - OpenGL Problems

Who is online

Users browsing this forum: No registered users and 3 guests