Re: [AD] al_convert_bitmap

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Tue, 2011-06-14 at 09:27 +1000, Peter Wang wrote:
> On 2011-06-13, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> > 
> > The goal with all that is simply to make it work how people expect it
> > without much fuss or complication. If somebody really wants full
> > control, then can simply disable auto conversion, mark things as
> > MEMORY and manually call al_convert_bitmap() later.
> > 
> > VIDEO|ANY doesn't mean much to me. It could be a distinction between
> > destroying a bitmap upon display creation or not.
> 
> That's a good idea.  Right now there is no way to express to Allegro
> that you don't care about a video bitmap after its display is destroyed,
> so the most efficient way to clean up a display and its bitmaps is to
> let al_uninstall_system() do it.
> 
> VIDEO (without ANY) would tell al_destroy_display() to destroy the
> bitmap (as far as possible) instead of converting it.  It would probably
> need to leave behind a zombie bitmap so that it does not crash when the
> user calls al_destroy_bitmap().  Zombie bitmaps can simply have neither
> VIDEO or MEMORY flags set.

Makes sense. So al_destroy_display simply would go through the display
bitmaps and remove the VIDEO flag from any bitmaps without the ANY flag
- meaning the only operation allowed on them from now on is calling
al_destroy_bitmap.

> > The absence of VIDEO and MEMORY would indicate to try video first then
> > fall back to memory. None of those three flags would mean try video,
> > then memory, and set auto convert. That would mean there would be no
> > way to say "I want a video or a memory bitmap but don't auto convert",
> > but I don't think that's a useful combination.
> > 
> > If the flags work together like that, then I think it makes sense that
> > VIDEO bitmaps without AUTO_CONVERT would be destroyed upon a displays
> > destruction.
> 
> Yes.
> 

We should avoid using the term "destroyed" in the documentation though
since unless you actually destroy those zombie bitmaps with
al_destroy_bitmap you still would create a huge memory leak on display
re-creation. Completely destroying them actually might be more
convenient - even if it does another bad thing of invalidating pointers
the user might still hold...

On Mon, 2011-06-13 at 11:55 -0500, Matthew Leverton wrote:
> Well, I suppose that's additional rationale for having it be an
> option:
> 0 => do nothing at all
> 1 => auto upgrade tagged bitmaps
> 2 => auto downgrade tagged bitmaps
> 3 => auto upgrade & downgrade tagged bitmaps (default)
> 
> ... just throwing out some possibilities.

We could provide bitflags instead of numbers:

NO_AUTO_MEM_VID = 1
NO_AUTO_VID_MEM = 2
NO_TRANSFER = 4

and then:

0: Auto-convert AUTO_CONVERT both ways and on destroy_display try to
transfer any bitmaps to another display (else either convert or zombify
depending on AUTO_COVNERT flag).

1: Same as 0 but never convert AUTO_CONVERT in mem->vid direction.

2: Same as 0 but never conert vid->mem (zombify instead).

3: Same as 0 but completely ignore AUTO_CONVERT.

4,5,6,7: Same as 0,1,2,3 but in al_destroy_bitmap never try transferring
to another display, instead behave as if it was the last display being
destroyed.

I'm not actually sure we need NO_TRANSFER, I guess it depends a lot on
the reason why you have multiple displays. If it's some game launcher
where you may want to open 4 windows with completely different games you
wouldn't want transfers for example (if the displays are not compatible
transferring many textures would be very slow)... but not sure that's a
very likely scenario.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>