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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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?)

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?

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

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.





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/