Re: [AD] Not freeing resources of non-preserved bitmaps on Android is considered harmful :)

[Trent Gamblin <trent@xxxxxxxxxx>]

After sleep, I realize that this change would break backwards compatibility... 
however, 5.0 never had an Android port and 5.1 is "unstable", so that may be 
OK... Thoughts on that?

On October 22, 2015 08:41:28 PM Max Savenkov wrote:
> The only case I'm aware of when context is lost, is when we suspend the
> application. The context will be lost, but there are two known workarounds:
> 
> 1) We can detach SurfaceView from Views hierarchy, and re-attach it when
> application is resumed. Then, the context won't be destroyed. (I haven't
> actually tried that, but it's popular on the net)
> 2) Make current context null during suspend (via call to
> eglMakeCurrent(m_display,EGL_NO_SURFACE,EGL_NO_SURFACE,EGL_NO_CONTEXT)),
> but before that, save current context ID. When app is resumed, use saved
> context id as a share_context parameter to eglCreateContext. Then, we will
> have access to all resources of the previous context. This is the method
> used by SDL and at my workplace.
> 
> The second method is what I would attempt to bring to Allegro, even thought
> it looks a bit leaky - we create a kind of a chain of shared contexts,
> because each time we suspend/resume an app, we create a new context that
> shares resources with previous one. However, I can't see it leading to
> anything bad, and it works, and is easier to pull of than the first method,
> which seem to require supplying our own hacked version of GLSurfaceView.
> 
> 2015-10-22 20:08 GMT+03:00 Thomas Fjellstrom <thomas@xxxxxxxxxx>:
> > On Thu 22 Oct 2015 11:05:03 AM Max Savenkov wrote:
> > > 22.10.2015 11:00, Trent Gamblin пишет:
> > > > On October 22, 2015 10:40:56 AM Max Savenkov wrote:
> > > >> I think I found another bug in Android implementation. For some
> > 
> > reason,
> > 
> > > >> in 'android_acknowledge_drawing_halt(ALLEGRO_DISPLAY *dpy)' Allegro
> > 
> > does
> > 
> > > >> not delete resources of bitmap if it has ALLEGRO_NO_PRESERVE_TEXTURE
> > > >> flag set. Since in reality FBOs and textures for those bitmaps are
> > > >> deleted when OpenGL context is deleted during suspension, this leads
> > 
> > to
> > 
> > > >> corruption after the game is resumed. I'm not very clear on details,
> > 
> > but
> > 
> > > >> somehow OTHER bitmaps may end up corrupted because of this.
> > > >> 
> > > >> I tried commenting out this flag and it seems to make everything
> > 
> > better
> > 
> > > >> :) So unless there is some remembered reason for it being there, I
> > > >> 
> > > >> propose to strike out this check.
> > > > 
> > > > I'll check this tomorrow.
> > > 
> > > Great.
> > > 
> > > >> Also, I'd like to question the whole approach Allegro takes to
> > > >> suspension/resuming on Android. Why doesn't it uses the same method
> > > >> as
> > > >> SDL, which preserves the whole OpenGL context, instead of
> > > >> re-uploading
> > > >> bitmaps after resuming? This would eliminate the difference between
> > > >> NO_PRESERVE_TEXTRURE and other bitmaps (as it should be with OpenGL)
> > 
> > and
> > 
> > > >> also preserve shaders (which presently has to be re-created as well
> > > >> during resuming). This would allow Allegro (or its user at least) to
> > > >> save memory by setting NO_PRESERVE_TEXTURE for all bitmaps and not
> > 
> > store
> > 
> > > >> in-memory copy of data. Is there any reason not to do so, or is it
> > 
> > just
> > 
> > > >> a historical decision?
> > > > 
> > > > If it's possible to preserve the context then NO_PRESERVE_TEXTURE
> > 
> > should
> > 
> > > > be a no-op on Android like on PC. If you wish to create a patch for
> > 
> > this
> > 
> > > > then I'll be happy to take a look at it.
> > > > 
> > > > Thanks.
> > > 
> > > Yes, it is possible, both SDL and Nya Engine (which we use at work for
> > > 3d) use this approach. I'll try to make a patch then, but it'll take
> > > some time. I'll post it if I succeed.
> > 
> > When the port was done, some devices with some versions of android just
> > plain
> > would lose the context and all data attached to it. And would lose it
> > somewhat
> > often. You couldn't actually tell it to keep the context. Everything was
> > manual. If that's changed, great.
> > 
> > > _______________________________________________
> > > Allegro-developers mailing list
> > > Allegro-developers@xxxxxxxxxx
> > > https://mail.gna.org/listinfo/allegro-developers
> > 
> > --
> > Thomas Fjellstrom
> > thomas@xxxxxxxxxx
> > 
> > _______________________________________________
> > Allegro-developers mailing list
> > Allegro-developers@xxxxxxxxxx
> > https://mail.gna.org/listinfo/allegro-developers
> 
> 2015-10-22 20:08 GMT+03:00 Thomas Fjellstrom <thomas@xxxxxxxxxx>:
> > On Thu 22 Oct 2015 11:05:03 AM Max Savenkov wrote:
> > > 22.10.2015 11:00, Trent Gamblin пишет:
> > > > On October 22, 2015 10:40:56 AM Max Savenkov wrote:
> > > >> I think I found another bug in Android implementation. For some
> > 
> > reason,
> > 
> > > >> in 'android_acknowledge_drawing_halt(ALLEGRO_DISPLAY *dpy)' Allegro
> > 
> > does
> > 
> > > >> not delete resources of bitmap if it has ALLEGRO_NO_PRESERVE_TEXTURE
> > > >> flag set. Since in reality FBOs and textures for those bitmaps are
> > > >> deleted when OpenGL context is deleted during suspension, this leads
> > 
> > to
> > 
> > > >> corruption after the game is resumed. I'm not very clear on details,
> > 
> > but
> > 
> > > >> somehow OTHER bitmaps may end up corrupted because of this.
> > > >> 
> > > >> I tried commenting out this flag and it seems to make everything
> > 
> > better
> > 
> > > >> :) So unless there is some remembered reason for it being there, I
> > > >> 
> > > >> propose to strike out this check.
> > > > 
> > > > I'll check this tomorrow.
> > > 
> > > Great.
> > > 
> > > >> Also, I'd like to question the whole approach Allegro takes to
> > > >> suspension/resuming on Android. Why doesn't it uses the same method
> > > >> as
> > > >> SDL, which preserves the whole OpenGL context, instead of
> > > >> re-uploading
> > > >> bitmaps after resuming? This would eliminate the difference between
> > > >> NO_PRESERVE_TEXTRURE and other bitmaps (as it should be with OpenGL)
> > 
> > and
> > 
> > > >> also preserve shaders (which presently has to be re-created as well
> > > >> during resuming). This would allow Allegro (or its user at least) to
> > > >> save memory by setting NO_PRESERVE_TEXTURE for all bitmaps and not
> > 
> > store
> > 
> > > >> in-memory copy of data. Is there any reason not to do so, or is it
> > 
> > just
> > 
> > > >> a historical decision?
> > > > 
> > > > If it's possible to preserve the context then NO_PRESERVE_TEXTURE
> > 
> > should
> > 
> > > > be a no-op on Android like on PC. If you wish to create a patch for
> > 
> > this
> > 
> > > > then I'll be happy to take a look at it.
> > > > 
> > > > Thanks.
> > > 
> > > Yes, it is possible, both SDL and Nya Engine (which we use at work for
> > > 3d) use this approach. I'll try to make a patch then, but it'll take
> > > some time. I'll post it if I succeed.
> > 
> > When the port was done, some devices with some versions of android just
> > plain
> > would lose the context and all data attached to it. And would lose it
> > somewhat
> > often. You couldn't actually tell it to keep the context. Everything was
> > manual. If that's changed, great.
> > 
> > > _______________________________________________
> > > Allegro-developers mailing list
> > > Allegro-developers@xxxxxxxxxx
> > > https://mail.gna.org/listinfo/allegro-developers
> > 
> > --
> > Thomas Fjellstrom
> > thomas@xxxxxxxxxx
> > 
> > _______________________________________________
> > Allegro-developers mailing list
> > Allegro-developers@xxxxxxxxxx
> > https://mail.gna.org/listinfo/allegro-developers