Re: [AD] Current display being changed somewhere?

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Mon, May 21, 2012 at 8:10 AM, Trent Gamblin <trent@xxxxxxxxxx> wrote:
> Before I go on a wild goose chase, and put printfs all over the place, does anyone know if/where the current display might be getting set where it wasn't before (within about the last 50 revisions?) The problem I'm facing is in lock_region_old, disp receives the value NULL from al_get_current_display. It's from the same thread as the display was created on and I never explicitly set the display myself. bitmap->display holds the correct value for the display at that point and using that everything works. Just in case it's important, the path leading up to this is: receive DISPLAY_CONNECT, call al_destroy_display on the only display (because I need to create two new ones), in that call al_convert_bitmaps locks a display bitmap and that's where the NULL value comes from. This was working like I said around 50 revisions ago. It doesn't look like that al_get_current_display line has changed at all so it could be anywhere that the problem cropped up, including my own code but as I said, it's in the same thread and I never change the current display or do anything display related from other threads. Any input is appreciated.
>

Well, al_destroy_display sets the current display to NULL in the
beginning. I guess how al_destroy_display *should* work is:

1) In the platform independent part of al_destroy_display, do the
bitmap conversion already. No point copying that everywhere.
2) Don't change the target bitmap or current display yet.
3) In display->vt->destroy_display, only do the platform specific
things (but possibly set the current display if required).
4) If the destroyed display is current, don't restore to it but set it
to NULL (and if its backbuffer was the target bitmap, set that to NULL
as well).

Right now it looks like the D3D, WGL and OSX drivers immediately set
the display back to the current display (so it's pointless to null it
in the platform independent part). And then all the drivers seem to do
the same bitmap conversion (except D3D and WGL). So yes, it's a bit of
a mess right now.

I suppose to fix your case you could just set the current display to
the destroyed display at the beginning of
display->vt->destroy_display.