@Jason: Thanks again for your inputs. > >If we keep the application up for long duration of time, this issue is > >seen more frequently. I meant - If we use the app for a longer duration of time without navigating out or switching to a different app we see Canvas Lock with Bad address.
>>You originally said after 15 - 20 >> switches back and forth, but this comment implies something else.) Even when we keep transitioning between activities quickly, after 15-20 tries, we observe the same "Lock Canvas" issue. So, for both the use-cases mentioned above we observe this issue. >> > 1. Could you show us how you perform these two tasks, your code? I'm > wondering if maybe the way you are doing it is leaking memory and eventually > failing, or otherwise not releasing / unlocking resources properly, > eventually reaching the limit. Here is how it is being done(cant share code): Assume there are 5 activites in the application. The first activity has a GLSurfaceView on which we render Bitmaps(drawing in DIRTY MODE). This activity is never finished. All the other "subsequent" activities are transparent. We are creating a Bitmap object per activity and storing them in a Stack. These bitmaps are rendered/cleared from the GLSurfaceView everytime an activity is Entered/exited from, using Broadcasts. After a bitmap object becomes useless in the context, we pop it from the stack, call recycle to free native memory and nullify the java reference. > 2. If you avoid using the bitmap at all (no rendering from / on it - don't > even create it), does the problem go away? Yes, if we remove the calls to GLSurfaceView.requestRender() the issue goes away. > 3. When you say 'captured and rendered', what exactly does the 'captured' > part mean? Captured from where? Captured = A bitmap object is created in code. On May 6, 10:04 am, "Jason Teagle" <[email protected]> wrote: > >If we keep the application up for long duration of time, this issue is > >seen more frequently. > > Here, do you mean you simply leave the application as the foreground app for > that length of time and it just 'happens', or do you mean the app is left at > the front and after a long time, when you suddenly move to another app and > back to yours it goes wrong [more often]? (You originally said after 15 - 20 > switches back and forth, but this comment implies something else.) I'm > trying to establish whether it is exclusively due to moving to another app > and back to yours or occurs in other situations. > > Going back to your original post, you describe capturing and rendering a > bitmap to a surface and then removing it on pause. > > 1. Could you show us how you perform these two tasks, your code? I'm > wondering if maybe the way you are doing it is leaking memory and eventually > failing, or otherwise not releasing / unlocking resources properly, > eventually reaching the limit. > > 2. If you avoid using the bitmap at all (no rendering from / on it - don't > even create it), does the problem go away? > > 3. When you say 'captured and rendered', what exactly does the 'captured' > part mean? Captured from where? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
