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
