Hi,
So I am in the midst of porting my game to windows, and then getting it onto greenlight on Steam and I have found that it runs incredibly slow (~10x slower) on a window laptop I am testing it on. The laptop isn't too bad, an i5 thinkpad win 7 4gb, and so should be able to handle a simple 2D board game without a problem.
I have narrowed the problem, causing the slowness down to a few al_set_target_bitmap() calls .
Even if the code is like this... (with no code between the calls)

al_set_target_bitmap (zbuffer_bmp) (where zbuffer is a bitmap the same size as the display)
al_set_target_backbuffer (display)

..it slows the game down massively and I am at a loss what it might be (I have already done the "obvious" checking for memory bitmaps, and whether vsync is on etc)

If I comment out the al_set_target_bitmap the game doesn't slow down.

Can any help or have any suggestions, thanks.

I'm curious why it's causing the game to slow down but...

Do you even need either of those function calls? I don't think you do, since Allegro automacally sets the target bitmap and target backbuffer when you create a display. Is there a problem you are trying to resolve by adding those functions?

I was merely reducing my code to the barest minimum to determine what caused the slowing, and whittled it down to those two lines, and in particular the first one. Normally I "flush" the zbuffer with al_clear_to_color, before returning to the backbuffer. Then a little later on in the function, when I draw the players cards, I also draw on the zbuffer, so I can later do a (locked bitmap) al_get_pixel_color on the zbuffer to see if the cards/hand are clicked/touched.
But it is the al_set_target_bitmap that causes the crippling slowness. I could code/hack around the problem, but I am loathed to before I understand what I am potentially doing wrong.

(I am using 5.2 and the windows binaries for the record.)

Can you please post more of the code that contains those two function calls? I think it's important to see any loops that are happening and where / how things are created / destroyed.

Try setting the ALLEGRO_NO_PRESERVE_TEXTURE flag.

Thanks the ALLEGRO_NO_RESERVE_TEXTURE did the trick, though I would like to know why it works for future reference, and would really appreciate if you can illuminate me or point me in the right direction/documentation.

Without that flag, Allegro automatically stores a copy of the texture in system RAM. If the graphics device is reset by some means (seems to be a thing on mobile platforms I believe, but also relevant for the older version of DirectX), texture data may be lost. In such a case, Allegro would use the copy to generate the texture, so the graphics device reset is handled silently. However, for a texture that is modified every frame, this is useless and instead incurs a performance penalty, as you witnessed.

(I think that's the gist of it.)

Is this feature automatically enabled on all systems?

DirectX 9.0c (the last before DirectX10, and the last normally supported on Windows XP) loses textures when alt-tabbing from fullscreen.
If you want to keep supporting it while still using ALLEGRO_NO_RESERVE_TEXTURE, maybe there's a clever trick like, instead of setting a FULLSCREEN mode, setting a DESKTOP-SIZED BORDERLESS WINDOW.

I think ALLEGRO_NO_PRESERVE_TEXTURE should be removed from Allegro (and should then be the new default, i.e. Allegro will never download textures behind your back) - it just completely breaks all programs using dynamic bitmaps. And then do something similar to iOS and Android where you can restore textures if/when needed.

I just force OpenGL usage so that texture preservation becomes a non-issue. The average person won't even notice nor care, plus given Microsoft's practices with legacy DirectX support, I think this is a better approach in the long run for keeping my games working their best through newer and newer versions of Windows.

This is really kind of a non-issue if you just use ALLEGRO_FULLSCREEN_WINDOW. :/

Is this really an issue with fullscreen only? Right now the DirectX port always has it on by default, even in windowed mode... if it's save to disable we probably should.

Thanks for enlightening me.
In my experience it didn't make a difference whether it I set the display flags to OpenGL or DirectX (it was one of the first things I did), they both slowed down on my two windows 7 machines.
I disagree that it is a non issue if you just use ALLEGRO_FULLSCREEN_WINDOW, although I conceed it is probably an expedient hack.workaround, which I have yet to try.
I think Elias is right about how preserving textures should be implemented.

I feel I should clarify what I said: Forcing OpenGL you STILL need to disable Allegro's texture preservation with the appropriate flag, it's just with OpenGL rendering and full-screen stuff, when you alt-tab out and alt-tab back in, your textures should still be there, regardless of how this is set.

I think internally, OpenGL just handles everything automatically, so even if textures are destroyed by switching, OpenGL restores them itfself. Would be quite useful if D3D also did that.