I did a traceview...
Monkey Targets Forums/Android/I did a traceview...
| ||
| My game is stuttering at the beginning of a level. I tried drawing all images to the screen to prevent this but I think the tablet's graphic memory can't hold all the images. here are the methods that take up all the time gxtksurface.bind children: self 44% java/NIO/ReadWritePixbufferput 44% here is the trace file: http://www.mediafire.com/download/b9wc55wcmpmsyf4/calc.trace |
| ||
| Strangely enough I have been doing much the same thing here. This is exactly the results I would expect to see based on the code. This is a particular problem for android when onSuspend is sent to the application (due to a popup or interstitial advert etc). I am in the process of testing my modifications to the android source for mojo to resolve this problem. The current implementation will pad the image (if not power of two) and then convert the pixel format while pre-rending the alpha every time the texture is bound. This is why all the time is being spent in the Bind() method. The solution I'm looking at involves performing all of this work upfront and storing the resultant pixel array. The downside is increased memory usage, but this does significantly reduce the garbage collection thrashing that I was seeing in my game as there are no allocations during the Bind() phase any more. Provisional results look very promising on one of my slower test devices (ZTE Blade), the it took up to 7 seconds for the textures to be prepared after returning from an interstitial advert - i.e. 7 seconds before the UI became responsive again. After my changes it took less than 0.2 seconds. This is an absolute game changer in terms of usability. If Mark is "listening" I would be very happy to contribute the changes assuming it continues to perform as expected during testing. The way I have it implemented at the moment its that it can be enabled or disabled through a pre-processor tag so it should be possible to integrate it into the core product without impacting any existing applications. |
| ||
| Oh please share, that would be great! Maybe each image could be tagged as important or not important. At the moment I am drawing each image that is used in a certain level before loading the level. This works for the first 2 but the other 2 are still experiencing stutter problems. |
| ||
| I have responded via email. Let me know how you get on. |
| ||
| Are you using texture atlases? |
| ||
| Maybe take a look at this old thread which dealt with both memory usage and speed of the binding operation: http://www.monkey-x.com/Community/posts.php?topic=2589&page=1 . The relevant stuff starts from around post 20. |
| ||
| Thanks for the heads up. An interesting read. I've taken a slightly different approach, but maybe a hybrid might provide the right balance. However I need to get this app launched before I get distracted with profiling again... :) |
| ||
| Okay, I have taken another look at this and I think Mark has already provided the best compromise solution. Providing you ensure that your images / image atlases are power of 2 sizes, rename the Bind2() function of gxtkSample in the mojo android source to Bind() and rename the existing Bind() function. This was you can use Mark's "experimental" code which although very slightly slower than my modifications, consumes far, far less memory and therefore is the better solution. Comparative timings below from Hop Or Pop on my test ZTE Blade device, using the three different methods. Time taken to bind all GL textures after returning to application (time in seconds) Current implementation: 8.4 My memory hungry solution: 0.04 Mark's Bind2(): 0.43 In terms of user experience there is no perceptible difference between Mark's solution and mine. I hope this helps some of you. |
   |