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

[Trent Gamblin <trent@xxxxxxxxxx>]

On 2012-05-25, at 11:23 AM, Elias Pschernig wrote:
> On Fri, 25 May 2012 11:06:33 -0600
> Trent Gamblin <trent@xxxxxxxxxx> wrote:
>> 
>> Here's the problem: Some of your bitmaps may depend on Allegro's and
>> vice versa. Either they need each other to redraw themselves, or
>> they're sub-bitmaps and you can't recreate them automatically in
>> Allegro because you destroyed all of your self-managed bitmaps and
>> you're reloading them after acknowledge_resume.
>> 
>> So it boils down to this: You may need to refresh some of your
>> bitmaps before Allegro does its own, and you may need to refresh some
>> after. Right now you can do it after, but not before. As I said, you
>> can't just place a call before acknowledge_resume because that
>> function sets up some state (makes context current etc).
>> 
> 
> Can you give a short code example?

Well there are a couple potential issues. This example is contrived just to show
them but in a complex program these dependencies can actually happen.

al_set_new_bitmap_flags(ALLEGRO_NO_PRESERVE_TEXTURE);
// This does: b->bitmap = al_load_bitmap(). store 'b' in some list
MY_BITMAP *b = my_load_bitmap
al_set_new_bitmap_flags(0);
ALLEGRO_BITMAP *a;
// Some fancy stuff to draw 'a' using 'b'
// This can have PRESERVE on or off
// Imagine a texture atlas with 1000 sub bitmaps
ALLEGRO_BITMAP *sub = al_create_sub_bitmap(b, x, y, w, h);

-- Get HALT --

// destroys everything created by my_load/my_create
// create could take a callback that programattically draws the image
destroy_bitmap_list()
acknowledge_acknowledge_drawing_halt();

-- Get RESUME --

// PROBLEM 1 with line below:
// 'sub' is restored in here from 'b' which was destroyed
// PROBLEM 2
// 'a' is also restored now with b which was destroyed
al_acknowledge_drawing_resume();
// b gets reloaded, the only one that loads properly
restore_bitmap_list();