I was actually going to post this same thing. It happens with the GDI driver and is most pronounced when doing lots of blits.

Run the Allegro demo with dirty rectangles in GDI to see it happen.

Another weird thing, at least on Vista, is that the GDI (I think) DX windowed display isn't always updated. For instance, when I run the demo and it tries to set a crazy 320x200 mode, after failing at several tries, it finally sets a windowed mode. However, nothing is displayed unless I move the Window around. The GUI for selecting the mode / update system isn't displayed as well.

Once the game starts, it works. And if I select GDI, I get the bouncing behavior. Attached a MingW32, static version of demo.exe in case anyone else wants to test that out.

Edit: It happens to the Direct X windows mode sometimes with GFX_AUTODETECT, 320, 200. After failing to set full screen, it then sets a windowed mode. Since the demo is in 8-bit, Vista shuts down its advanced graphics display. Then sometimes there is nothing displayed in the window. But sometimes it works. And if I use GFX_AUTODETECT_WINDOWED it doesn't ever seem to do it.

Edit 2:

Setting top_line to 0 inside the if{} fixes it. I'll try to see why.

Edit 3: What's odd is that it doesn't happen until after the Allegro logo zooms up. I changed it to be like this:

top_line = toggle ? 16 : 0;
toggle = 1 - toggle;

And as soon as the logo is finished zooming, it starts jumping by 16 pixels.

Edit 4: The problem, I think, is here (stretch_blit_to_hdc @ gdi.c):

  StretchDIBits(dc, 
    dest_x, dest_y, 
    dest_w, dest_h, 
    src_x, bitmap->h - src_y - src_h, 
    src_w, src_h, 
    pixels, bi, DIB_RGB_COLORS, SRCCOPY);

Allegro's GDI bitmaps are top down DIB, created by using a negative height. From what I can gather StretchDIBits always works with bottom,left thus the weird src_y calculation. (That goes against what the MSDN documentation says.)

However, with top-down DIBs there is some sort of bug (?) with certain sx,sy (0,0 ?) coordinates that causes the behavior to be reversed. But I cannot figure out what it is.

When I switch Allegro to use bottom-up DIBs, then the jerkiness goes away, but everything is upside down (and some artifacts appear, but probably due to my hack). If I then swap the dest_h and dest_y to be negative, it flips it right side up (and the jerkiness is still gone).

Edit 5: Changing stretch_blit_to_hdc @ gdi.c to this, "fixes" the problem by not drawing the left most line:

The problem is if you are blitting the source rectangle of (0,y1)-(x2,bmp->h) with y1 > 0, then everything is drawn from (0,0) [using coords from the top-left]. So, for example: if you are blitting from (0,16)-(0,479) to (0,16), then you really get (0,0)-(0,463) drawn at destination (0,16). But if x1 != 0 or y1 == 0, then it's fine.

So we need an expression that is able to represent that case without triggering the error. Perhaps something can be done with negative heights (those are treated as flipped), but nothing is working yet.

Edit 6: I think this solves the problem:

StretchDIBits(dc, 
  dest_x, dest_h+dest_y-1, dest_w, -dest_h,
  src_x, bitmap->h-src_y+1, src_w, -src_h, 
  pixels, bi, DIB_RGB_COLORS, SRCCOPY);

Just replace the current StretchDIBits line with that one.

Attached is an updated DLL. Please test it out to see if it fixes the problem for you.

I wrote a complete description of the problem on the wiki, and will send a patch to the mailing list.

Just for reference, this is a test program:

With Allegro 4.2.1 the bottom rectangle is never seen on the screen because Windows actually blits the top half of the buffer since the rectangle touches the bottom left corner! The full screen rectangles and top rectangles are fine. [The readkey()'s after the clear()'s are necessary to prevent the full screen from being refreshed by the clear().]

With my patch, all three cases work. Hopefully it doesn't introduce any other weird problems.

It's compiled by MinGW, which produces larger DLLs than MSVC.

Try this DLL as well. It only runs the new code for the problem case. (As I wrote on the Wiki, it's possible that this reverse blitting is slower.)

Is this only in Vista? I have never experienced this problem in 98SE or XP. I'm not very happy about taking a 10% performance hit for the sake of a Vista bug, which may be temporary. If the lib is patched, can you make sure you comment it so it can be reversed later?