Hi. I am using Allegro 5.2.2.1 (I think, not sure how to check) from the Nuget packages. I'm not set up with a dev build of Allegro yet, so I can't be too specific about the cause of this problem yet. I figured I'd start a thread and see if anyone had any ideas first.

I am trying to track down some performance issues. I'm running in windowed mode (not full-screen windowed) under Windows 10. I have an "overlay" bitmap that I regenerate every frame and then render on top of everything else.

My performance issue was tracked down to some code that reads:

ALLEGRO_BITMAP *former_bitmap = al_get_target_bitmap();
al_set_target_bitmap( mSurface ); //****** THIS IS CRAZY SLOW ******
al_clear_to_color( al_map_rgba( 0, 0, 0, 0 ) );
al_set_target_bitmap( former_bitmap );

The only line that is running slowly is that first al_set_target_bitmap call. Some initial Googling suggested that I should create mSurface with ALLEGRO_NO_PRESERVE_TEXTURE (https://www.allegro.cc/forums/thread/616223), but it doesn't make any noticeable difference to the performance. I did call al_get_bitmap_flags after creating it to verify that ALLEGRO_NO_PRESERVE_TEXTURE was set--it was.

I stuck a high-resolution timer in there, and it is showing that this single line of code takes about 0.004 seconds in debug mode (MSVC), and about 0.0146 seconds in release mode. You are reading that correctly: debug mode is much faster than release mode . I get the same behavior on both 32- and 64-bit builds, so it's not that either.

Can anyone suggest what I should try next?

EDIT: The problem goes away if I remove ALLEGRO_OPENGL from my initial call to al_set_new_display_flags (previously: ALLEGRO_OPENGL | ALLEGRO_RESIZABLE | ALLEGRO_WINDOWED; much faster when using: ALLEGRO_WINDOWED | ALLEGRO_RESIZABLE). This seems to be an OpenGL-only issue.

Thanks for the thoughts. Unfortunately, I would need to have a development version of Allegro to trace into al_set_target_bitmap, and all I have is the nuget binaries. It would take me a couple of hours to switch to a development build, so I'm not sure when I'm going to get around to it.

While I probably don't need to redraw the entire intermediate bitmap every frame, drawing at least one small thing to it every frame is going to be very common (it's a kind of heads-up-display overlay that lies on top of the play area). There are certainly other ways to accomplish this, but the main point of interest here is the bizarre "worse performance in release mode" issue. That shouldn't happen [almost] no matter what I'm doing. Even if I rewrote this particular piece of code, there are lots of reasons that I might want to draw to other bitmaps every frame--or even every few frames. But that kind of performance hit for switching render targets makes the whole system unusable for real time rendering, unfortunately.

I tried to reproduce this, but couldn't on my Win7. Here's the code I used:

al_set_new_display_flags(ALLEGRO_OPENGL);
auto* d = al_create_display(800, 600);
auto *b = al_create_bitmap(200, 200);
for (int i = 0; i < 10000; i++) {
  al_set_target_bitmap(b);
}
double start = al_get_time();
for (int i = 0; i < 1000; i++) {
  al_set_target_bitmap(b);
  al_clear_to_color(al_map_rgb_f(1.0, 0.0, 0.5));
  al_set_target_bitmap(al_get_backbuffer(d));
}
printf("taken: %f\n", al_get_time() - start);
al_rest(5.0);

That takes about 0.02 secs on my system. I don't actually have a real install of Win10, but I guess that's the next step to try.

Are you using 'real' OpenGL drivers (those vendored by the GPU manufacturer?).

al_flip_display() waits for vsync with OpenGL, so each call will take 0.0167 seconds.