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

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Fri, 25 May 2012 13:12:01 -0600
Trent Gamblin <trent@xxxxxxxxxx> wrote:

> On 2012-05-25, at 12:59 PM, Elias Pschernig wrote:
> 
> 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.

Ah, I misunderstood. But isn't that what the event is for then? What
would be the difference between the callback and the event?

> 
> 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.

Yes, it's actually how I use ALLEGRO_BITMAP as well. Anyway, the
difference with that "lost" state would have been that sub-bitmaps would
have kept working - if you call al_destroy_bitmap then it means you
have to first destroy all sub-bitmaps. Myself I handle sub-bitmaps by
having a "MY_BITMAP *parent" in MY_BITMAP and re-creating the complete
sub-bitmap hierachy. I still use Allegro's sub-bitmaps for them since
the wrapper for al_draw_bitmap is much simpler that way obviously - but
I can always re-create those.

Anyway, yeah, guess the "lost" bitmaps don't help - the problem really
is how sub-bitmaps work.

> > 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.
> 

Is there any problem with how LOST/HALT and FOUND/RESUME work when not
dealing with sub-bitmaps? It seems to be rather simple for the case of
normal bitmaps - Allegro has the list of all display bitmaps for the
display (either with the NO_PRESERVE_TEXTURE flag or without) and does
the right thing for each either before generating the event or after
receiving the acknowledge.

If that's the case, then we really should fix sub-bitmaps instead of
adding some other mechanism just to deal with them (but acknowledge
for all of those events does seem to make sense to me anyway).

And for sub-bitmaps, I guess we want to change them to work as
references either way (before 5.2). I'd like to say I'll volunteer
and do it... but not sure when I'll find time. (Was wasting my
Allegro-allocated time with Diablo3 lately, sadly :P)