Re: [AD] Duplicate "surfaceCreated" on Android - explanation needed

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


OK thank you, I'll try this soon and let you know...

-----Original Message-----
From: Max Savenkov [mailto:max.savenkov@xxxxxxxxxx
Sent: October 20, 2015 2:58 PM
To: Trent Gamblin <trent@xxxxxxxxxx>; allegro-developers@xxxxxxxxxx
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:max.savenkov@xxxxxxxxxx]
> Sent: October 20, 2015 2:18 PM
> To: Trent Gamblin <trent@xxxxxxxxxx>; allegro-developers@xxxxxxxxxx
> 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:allegro-developers-bounces@xxxxxxxxxx]
>> On Behalf Of Max Savenkov
>> Sent: October 20, 2015 2:00 PM
>> To: allegro-developers@xxxxxxxxxx
>> 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
>> Allegro-developers@xxxxxxxxxx
>> https://mail.gna.org/listinfo/allegro-developers
>>
>>
>
>






Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/