I committed your fix just now, seems to still work on the games I tested. Thanks!
-----Original Message----- From: Allegro-developers [mailto:[email protected]] On Behalf Of Trent Gamblin Sent: October 20, 2015 3:15 PM To: 'Max Savenkov' <[email protected]>; [email protected] Subject: Re: [AD] Duplicate "surfaceCreated" on Android - explanation needed OK thank you, I'll try this soon and let you know... -----Original Message----- From: Max Savenkov [mailto:[email protected]] Sent: October 20, 2015 2:58 PM To: Trent Gamblin <[email protected]>; [email protected] Subject: Re: [AD] Duplicate "surfaceCreated" on Android - explanation needed OK, I think I found the problem: when the game is suspended, "surface" member in AllegroActivity is not null-ed (even though its inner EGL surface is destroyed), therefore when we resume app, we already have an undead SurfaceView, for which system calls surfaceCreated. A patch would be just a call to destroySurface(); as a last line in public void onStop() in AllegroActivity.java. I tested it, and with it, I'm no longer getting duplicate events, and no new bugs appeared. 20.10.2015 23:20, Trent Gamblin пишет: > Yeah, sounds like a bug if you get two resume events. I can test my > games if you come up with a patch (as a way of verifying we're not > breaking any existing code...) > > -----Original Message----- > From: Max Savenkov [mailto:[email protected]] > Sent: October 20, 2015 2:18 PM > To: Trent Gamblin <[email protected]>; [email protected] > Subject: Re: [AD] Duplicate "surfaceCreated" on Android - explanation > needed > > Well, at the very least, it leads to all bitmaps being re-uploaded > twice, which is a waste of time. But in my case, it also leads to a > confusion: > > I have some textures with NO_PRESERVE_TEXTURE flag set, because I need to > update them often from game code. When the game is resumed, I need to > re-create their content (since it was not preserved during suspension). > But when I should do it? I get RESUME_DRAWING (and also SWITCH_IN and > RESIZE) events twice. If I try to re-create my textures both times, they end > up with garbage somehow. If I only re-create them after the second set of > events (when true AllegroSurface is created), things go better (though still > with problems - loss of Alpha, for example, - which I'm going to try to > pinpoint later). > > Even though I can kinda work around this problem, workarounds are ugly, and I > would very much prefer Allegro not to send me two sets of events. > > You may not notice this problem unless you have bitmaps you need to re-create > by hand, because automatic bitmaps work perfectly, even thought there is some > overhead. > > 20.10.2015 23:08, Trent Gamblin пишет: >> Sorry Max, think I sent you an email directly... >> >> What do you mean by "it ends in chaos"? In my experience it works fine. >> >> -----Original Message----- >> From: Allegro-developers [mailto:[email protected]] >> On Behalf Of Max Savenkov >> Sent: October 20, 2015 2:00 PM >> To: [email protected] >> Subject: [AD] Duplicate "surfaceCreated" on Android - explanation >> needed >> >> From what I understand from documentation >> (https://source.android.com/devices/graphics/architecture.html), a Surface >> is created automatically for SurfaceView (AllegroSurface, in our case), >> whenever it is about to become visible ("When the SurfaceView's View >> component is about to become visible, the framework asks the WindowManager >> to ask SurfaceFlinger to create a new Surface."). However, I see that >> AllegroActivity has a "createSurface" method, which creates a new >> AllegroSurface explicitly. >> >> When I minimize my game and restore it, I get the following log: >> >> ============================================ >> AllegroEGL: destroying egl_Surface >> AllegroEGL: destroying egl_Context >> AllegroSurface: surfaceDestroyed end >> AllegroActivity: onSaveInstanceState >> AllegroActivity: onStop. >> // Here, the game is paused and restored >> AllegroActivity: onRestart. >> AllegroActivity: onStart. >> AllegroActivity: onResume >> allegro : android D 24548: android_system.c:303 >> Java_org_liballeg_android_AllegroActivity_nativeOnResume [ 69.49768] resume >> activity >> allegro : android D 24548: android_system.c:316 >> Java_org_liballeg_android_AllegroActivity_nativeOnResume [ 69.49773] >> got >> display: 0x5d55fd20 >> AllegroActivity: postCreateSurface >> AllegroActivity: onResume end >> Choreographer: Skipped 388 frames! The application may be doing too >> much work on its main thread. >> AllegroSurface: surfaceCreated >> // Later: >> D AllegroActivity: createSurface >> // ... lots of action ... >> D AllegroActivity: createSurface end >> AllegroSurface: surfaceCreated >> allegro : display D 24548: android_display.c:43 >> Java_org_liballeg_android_AllegroSurface_nativeOnCreate [ 103.95028] >> nativeOnCreate >> allegro : display D 24548: android_display.c:50 >> Java_org_liballeg_android_AllegroSurface_nativeOnCreate [ 103.95049] >> AllegroSurface_nativeOnCreate >> D AllegroSurface: Grabbing focus >> AllegroSurface: surfaceCreated end >> >> ============================================ >> >> As you can see, Allegro gets "surfaceCreated" callback twice: first time, as >> per documentation, it happens right after onResume. The second time, it >> happens when postCreateSurface finally had a chance to run its way. >> Unfortunately, each "surfafeCreated" callback leads to spawning of >> RESUME_DRAWING events and bitmap re-creation. It ends in chaos. >> >> So, two questions: >> >> 1) Why does Allegro creates surface explicitly, when it is should be created >> automatically? Is the observed behaviour a bug, or intended? >> 2) Is there any way to avoid duplicate events & bitmaps re-creation? >> >> _______________________________________________ >> Allegro-developers mailing list >> [email protected] >> https://mail.gna.org/listinfo/allegro-developers >> >> > > _______________________________________________ Allegro-developers mailing list [email protected] https://mail.gna.org/listinfo/allegro-developers _______________________________________________ Allegro-developers mailing list [email protected] https://mail.gna.org/listinfo/allegro-developers
