Thank you Christopher.
I have a custom draw maze routine that splits the screen into 1488 x 25 pixel squares, which are detected by a rectangle drawn by the mouse. Each of these 1488 squares are stored in a vector as structs.
Now initially cycling through the saved custom maze and drawing it to screen is not a problem, since this is done just once before the main game loop. So then, by erasing the whole screen, the only way I knew how to get the maze back was to cycle through all 1488 squares again, calling: al_draw_bitmap() 1488 times for each frame. This worked but increased CPU from averaging 1 percent to about 12 percent.
Happily I've just found this works great:
ALLEGRO_BITMAP *MazeScreen = NULL;
MazeScreen = al_create_bitmap(WIDTH, HEIGHT);
(My cycle and draw maze loop)
al_draw_bitmap(MazeScreen, 0, 0, 0);
Above is what I now do before the main game loop to load the maze. Then I just: al_draw_bitmap(MazeScreen, 0, 0, 0); once per frame.
It now still only averages 1 percent CPU.
Initially I didn't think this would work since the same amount of screen update was happening. But now I think I was being a bit silly, because if just updating the whole screen area uses this much CPU, then that seems a bit extreme to me.
So my best guess is it's the huge number of calls to: al_draw_bitmap() that was the problem and Not the total screen updated area.
Thank you all. I'm extremely pleased.
Edit: So far though I've experienced no invalidation of the buffer pixels in any Windowed mode, so I've not needed to consider this before using FullScreen without using al_clear_to_color(), whereas I was using it with: al_clear_to_color() in earlier testing.