Re: [AD] al_acknowledge_drawing_resume(ALLEGRO_DISPLAY *, void (*user_reload)(void))?

[Trent Gamblin <trent@xxxxxxxxxx>]

On 2012-05-25, at 12:59 PM, Elias Pschernig wrote:
> On Fri, 25 May 2012 12:12:55 -0600
> Trent Gamblin <trent@xxxxxxxxxx> wrote:
>> Another possibility I was thinking of was making the restoration of
>> Allegro backed-up bitmaps a function the user calls themselves. I
>> don't know if that breaks backwards compatibility badly. It should
>> work (needs testing though) in this particular case. In the case of
>> DISPLAY_LOST/FOUND with D3D, we actually have to add "acknowledge"
>> function for it and if we can it would be cleaner to remove the
>> callbacks which I don't think anyone uses. I can test all this and
>> implement it if it's a good idea. I'm not sure.
> I suppose especially for the new "al_create_custom_bitmap" it would
> make sense. (Or is the custom bitmap upload callback already that new
> callback, in that case?)

I don't really follow. What I meant was one function that restores all "lost"
bitmaps from memory backup. So bitmaps created without
ALLEGRO_NO_PRESERVE_TEXTURE.

> And if the LOST event also gets an acknowledge function, maybe LOST and
> HALT could be combined? LOST still allows the use of drawing functions,
> but it probably doesn't make much sense. So if you're already going to
> listen to LOST events, might as well handle them exactly like HALT
> events and stop drawing until the FOUND/RESUME event. Or is there a use
> case where you would do different things for them?

I can't think of one of the top of my head.

> Also was thinking... would it help for your use cases if we allowed
> bitmaps which are in a "lost" state? Basically if a bitmap which has the
> NO_PRESERVE_TEXTURE flag set gets lost it goes into that "lost" state.
> 
> Then when you later lock such a bitmap or set it as target bitmap, it
> would get re-created. So there would be no more need to optimize memory
> use while an app is in the background on IOS/Android, because Allegro
> wouldn't use any memory for such bitmaps, instead just know they are
> completely "lost".

That wouldn't really help any. It would be bad actually. Right now it's up
to the user to handle those bitmaps. For example, in some cases I either
reload bitmaps from disk, recreate them programmatically, or both. The
ones I don't need to have any "content" I just recreate with al_create_bitmap.
The code that does this is pretty simple. Whenever I load or create a bitmap
with ALLEGRO_NO_PRESERVE_TEXTURE set, I store it in a list. I also
have some extra parameters to my load/create functions that allow passing
in a callback and some data (and a destroy function optionally) that will
get run each time the app is resumed, so it can load a bitmap then draw a
pattern on it for example. No memory is wasted as those bitmaps are
destroyed (literally with al_destroy_bitmap) on HALT. The way I can do that
is I have a wrapper of ALLEGRO_BITMAP that's just:

struct MY_BITMAP {
   ALLEGRO_BITMAP *bitmap;
};

I use MY_BITMAP everywhere you'd use ALLEGRO_BITMAP. Of course
that means I have to basically wrap a lot of Allegro's drawing and bitmap
handling code, but I suspect any large project would have to or want to
do that, if for no other reason than supporting multiple backends.

> At the same time, we probably should re-design sub-bitmaps to just be
> very lightweight references instead of full-blown bitmaps who just
> happen to share their memory with a parent.
> 
> For the implementation this means every function using bitmaps needs to
> be updated to deal with those new lightweight sub-bitmaps - I'd have
> to look at some code to know how much changes would be required in
> general for this.
> 
> But in return it would solve all the bitmap restoration issues in one
> sweep, since sub bitmaps don't matter for it any longer at all. And it
> would also make it easy to allow changing the parent of a sub-bitmap
> (or have no parent at all) or re-position or re-size sub-bitmaps.

I agree with this. Sub bitmaps having an ->extra really confused me
before I knew about it. Still doesn't make much sense to me.

Trent