This is something I've noticed: Locking a bitmap under Allegro is very slow. For video bitmaps this is expected, as the texture data has to be downloaded from the GPU and then re-uploaded, however it's been my experience that, even with memory bitmaps, calling al_lock_bitmap is very expensive when you would expect it to be instantaneous as the bitmap data is already in main memory.

edit: Nevermind, disregard: Turns out I screwed up the bitmap flags and was actually creating video bitmaps after all. Oops. Just to clarify, I use memory bitmaps in some places because performing pixel-level manipulations on them is fast, so they can be used to compose an image in software (using color matrices, etc.) and then convert it to a video bitmap once it's done.

For video bitmaps, you can lock it WRITE_ONLY, which should only allocate a memory copy to be uploaded later, or READ_ONLY, which should only download the texture data. At least that's what I would expect Allegro to do.

As for memory bitmaps, I agree, ideally it should only return a pointer to the data, which should be instant.

I'm not familiar with allegro's internals though, so I can't say what it really does.

Edit
I didn't see your edit til now. So locking a memory bitmap is not slow then?

No, locking memory bitmaps actually does seem to be fast, at least al_lock_bitmap() stopped showing up on the hot-path in the profiler once I fixed the flags. What IS slow is you try to al_draw_bitmap() a memory bitmap directly (without conversion), which seems fair enough.