Edit
I should note, I am using the DIRECT3D driver and MinGW 4.8.1 on Windows 10. When I use the OPENGL driver, it does not crash. This is with Allegro 5.1.13.

Hello all,

I am trying to resize an allegro window. When I get the RESIZE event I call al_acknowledge_resize, and then I recreate the ALLEGRO_BITMAP* buffer I am using. However when I then go to flip the display after drawing draw my buffer to the screen, it segaults in al_draw_scaled_bitmap. Here is the backtrace :

So the _display of the bitmap I am drawing is NULL, and the render_target member of the d3d_disp is NULL as well.

Any ideas what I am doing wrong? When I recreate the buffer I set the target backbuffer to the display to make sure the buffer will be associated with the display. I can show code, but I'm not sure what to show.

Here is what I am using

      if (redraw) {
         
         display.DrawToBuffer();
         if (clear_buffer || temp_clear) {
            al_clear_to_color(al_map_rgb(0,0,0));
            temp_clear = false;
         }
         spiraloid.Draw();
         display.Flip();
         
         redraw = false;
      }

         if (ev.type == ALLEGRO_EVENT_DISPLAY_RESIZE) {
            printf("ALLEGRO_EVENT_DISPLAY_RESIZE received.\n");
            display.AcknowledgeResize();
            spiraloid.SetSpiraloidTransform(display.CX() , display.CY() , display.SX() , display.SY());
            redraw = true;
         }

void Display::AcknowledgeResize() {
   al_acknowledge_resize(display);
   
   if (!fs) {
      ww = al_get_display_width(display);
      wh = al_get_display_height(display);
      CreateBuffer(ww,wh);
   }
}

There's a bug with resizing inside the Direct3D driver, see https://github.com/liballeg/allegro5/issues/565 for a bit of a discussion. Try sticking a little rest before creating the buffer or adding a `al_convert_bitmaps` call before you draw. I forget what the workaround is...

Is there any way I can help debug this?

I noticed that the _display member of my bitmap is NULL. I tested this with your test program, and used al_set_new_bitmap_flags(ALLEGRO_VIDEO_BITMAP); and creation of video bitmaps after resizing the display fails.

Edit
One other thing I noticed is that it is failing to release the video textures.

d3d      W C:\mingw\LIBS\A5113release\allegro\src\win\d3d_disp.cpp:2423 _al_d3d_destroy_bitmap           [   0.36914] d3d_destroy_bitmap: Release video texture failed.
d3d      W C:\mingw\LIBS\A5113release\allegro\src\win\d3d_disp.cpp:2434 _al_d3d_destroy_bitmap           [   0.36920] d3d_destroy_bitmap: Release render target failed.
display  I C:\mingw\LIBS\A5113release\allegro\src\display.c:240  al_resize_display                [   0.36922] Requested display resize 600x400

Yep, all that information is in that bug report. The current best guess is that those failing releases are causing the device to not be reset properly, and while it is in that non-reset state, all video bitmaps will fail to create (and fall back to memory bitmaps).

I haven't had the chance to fully read this yet, but here is some interesting reading on D3D resources and resetting devices.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb174714%28v=vs.85%29.aspx

So that failure to release the video texture is preventing us from resetting the D3D device.

Yipes. That's just one of the reasons D3D9 really blows. From what I know, later D3D versions to have this problem anymore. So... anyone in for an Allegro 6?

From d3d_destroy_bitmap :

IUnknown::Release() only returns 0 when all references to the interface are released. So there's extra references floating around out there somewhere that haven't been released yet.

Should be fixed on master now.

I'm on origin - should I change that?

Also, where was the leak?

It happened whenever you set the target bitmap. Here's the commit that fixed it: linky. Good thing I'm not paid by lines of code .

'origin' is just what the git remote is called. 'master' is the branch. Just do a git fetch origin and then git checkout master and that should get you where you want to be.

EDIT:

Forgot to reply to this... there's no technical reason why you couldn't add a DX1x backend to Allegro 5.x even now.

True, up to D3D11 should be no problem. Going up to D3D12 might be a different story, since it works fundamentally differnt and you'd want to make best use of it. Then again, I don't know if Allegro would really profit much from that in the first place. Most of the time, it's used for simple 2D games, which work perfectly fine in older versions of D3D and Open GL, anyways.

Well that fixed it! I can resize perfectly with the D3D driver and 5.2.0 now! Minimize, maximize, and restore work too, but strangely they are not available when I right click on the taskbar icon (Windows 10). It still stretches the screen until you let go, which is kind of ugly though. I wish I could keep redrawing in the meantime.

If there were a function to filter events out of the queue, that would be perfect. That way every time you get a resize event you could just collect them all at once. I've done that kind of thing before, and there are usually only 3-5 events piled up in the queue at a time.

I had a crash like Edgar, but I just switched to OpenGL to get it working.
I may try with the patch and revert to original settings and see if I have the crash.