Re: [AD] al_convert_bitmap

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2011-06-15, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> On Wed, Jun 15, 2011 at 1:19 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> >
> > They should be 0x0 bitmaps without any data associated.
> >
> > We should allow al_create_bitmap to create 0x0 bitmaps anyway
> > (if we don't already).
> >
> 
> Yes. Still, you have to call al_destroy_bitmap on them or you leak the
> ALLEGRO_BITMAP struct when the display is re-created. So the
> difference is just that with the zombification the user can destroy
> them after al_destroy_display - else we'd force them to destroy them
> before al_destroy_display (or not at all as we'd do it in
> al_destroy_display - just the pointers would get invalidated that
> way).

Invalidating pointers is a no-go.  As a user, you can't even go through
a list of bitmap pointers and figure out which ones to discard after
calling al_destroy_display.  You'd have to go through the list first,
predicting which ones will be invalidated.  If you get it wrong, you get
a crash or a memory leak.  Even if you get it right, the implementation
still might change in the future.

> > I don't care for auto-conversion anyway so I'm still hoping you will
> > remove it from al_create_display and retract
> > al_convert_all_video_bitmaps...
> >
> 
> Well, my problem is always that personally I don't care too much
> either as I'm mostly using Allegro through my wrapper which doesn't
> support multiple windows and already handles on-demand re-loading and
> on-demand texture-uploading of bitmaps.

If nobody wants it, let's not add it ;)

> 
> But for someone new to Allegro I feel it's hard to understand why the
> order of al_create_bitmap/al_create_display should matter. And on
> secondary thought why calling al_destroy_display followed by
> al_create_display would cause a massive slow-down for no apparent
> reason. We shouldn't expose technical details to the API that way.

I hardly think it's that complicated.  To use any API effectively you
need *some* idea of what is going on behind the abstraction.

> I kinda would see an appeal in if we had gone a really low-level route
> from the beginning. Do not keep a list of bitmaps in each display.
> Have al_create_bitmap return NULL if there is no ALLEGRO_MEMORY flag
> but no display. Get rid of the ALLEGRO_NO_PRESERVE_TEXTURE flag and
> have the user handle their list of video bitmaps whenever they
> re-create a display or get an ALLEGRO_EVENT_DISPLAY_LOST message. But
> the way it is in 5.0 we already made things quite user-friendly, just
> leaving that one issue where bitmaps can sometimes silently end up as
> memory bitmaps.

I think there is a happy medium.

Peter