Re: [AD] al_convert_bitmap

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Thu, 2011-06-09 at 11:22 -0500, Matthew Leverton wrote:
> > One thing which needs thought is when i call al_load_bitmap with the
> > new VIDEO flag - it will return NULL and I'd have to load the same
> > bitmap a second time.
> >
> Then why request a video bitmap if you don't really want one?

My line of thought is, why would I ever call al_load_bitmap or
al_create_bitmap if I don't want a bitmap? The use cases I'm thinking of
whenever I use the VIDEO flag if it fails I would then repeat whatever I
did with MEMORY anyway (so could have used ANY right away).

> What if there is a display present, you have VIDEO set and it fails
> because it's too big? You currently have to manually check and create
> a memory bitmap.
> 
> Allegro has a split personality regarding this. If you try to create a
> huge bitmap before a display, it will happily create a memory bitmap
> of that size. It will later then try to convert it and fail. But if
> you create that same bitmap after a display, it will return null.

Maybe it should just return a memory bitmap if it's too big? I think
that would fit to what I'm having in mind now.

> This is why there should be three types that the program can request:
> 
> any: try video first, then memory. It does this even if there is an
> active display. default behavior.
> video: only try video. If no display, then this fails immediately.
> memory: only try memory.

Yes, I guess the difference is (if it's changed to never return NULL any
longer):

set_flags(ANY)
bmp = al_load_bitmap(...)
if (is_memory_bitmap(bmp)) {
    ... split into video bitmaps
}

vs.

set_flags(VIDEO)
bmp = al_load_bitmap(...)
if (!bmp) {
    set_flags(MEMORY)
    bmp = al_load_bitmap(...)
    ... split into video bitmaps
}

I just prefer the first one.

> If we auto convert, then the "any" bitmaps would auto convert at
> display creation. Since it would be the default flag (0), bitmap
> creation would generally always succeed and always end up video
> bitmaps after a display is created. (Also any "video" bitmaps that
> were downgraded to "memory" due to previous display being destroyed
> would also be converted.)
> 
> I don't mind if auto-conversion is the default behavior, but I would
> make it optional and keep the convert-all function around. i.e.:
> 
> al_set_new_display_flags(ALLEGRO_AUTO_UPLOAD_BITMAPS, 0); // defaults to 1
> 

Makes sense. Especially when there's two displays it might make sense
not have the flag on.

> Now the average user is happy because he doesn't know any better, and
> the more advanced can still explicitly say when and where to convert
> the bitmaps.
> 
> And I think tags can be useful, but I agree that the user could just
> manage that themselves. Probably better that way since Allegro doesn't
> normally get too high level like that.
> 

Hm, the one case I keep ending up at is if I have 4 threads, 2 loading
threads and 2 display threads. The displays are incompatible so I'd tag
bitmaps of each loading thread with a different tag to then convert them
to video bitmaps in their display thread. But it's rather contrived.

Actually, another use for tags could be fonts. If I load a bitmap font
in another thread there currently is no way to convert it (since we
don't have al_clone_font/al_convert_font). If the font's bitmaps would
be tagged they could still be converted.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>