[AD] Recent 4.3 change?

[Chris Robinson <chris.kcat@xxxxxxxxxx>]

I recently woke up, so I don't know how old this is, but one of the bots 
alerted to a commit:

<juvbotz> Allegro updated, r7433 [peterhull90]
<juvbotz> Simulation of video bitmaps, so that page flipping will work

Assuming this change was for 4.3, I really think this should be reverted and 
properly discuessed.

I don't think it is Allegro's place to be emulating video bitmaps when the 
driver doesn't support them (let alone to allow page flipping, which is 
supposed to be abstracted away in the new API anyway so Allegro can pick the 
best update method). It's a big cause of slowdown in the X11 driver as it 
makes twice the work (attempt to draw to the actual screen as well as the 
memory bitmap emulating a video surface every time you draw to "VRAM"), and 
can lead to odd little errors when what's drawn to the screen is slightly 
different than what Allegro draws to the video emulation bitmap.

In 4.2 we can't really get away without making a "backup" of the screen, since 
screen updates are completely arbitrary by the user (though even still, I 
don't support extending the screen backup bitmap to behave like a larger VRAM 
surface; I've argued to remove this ability from the X11 driver). However, as 
I've mentioned in the OpenGL thread, using the new API there's no direct need 
for Allegro to keep a backup of the screen. With the new API, you'll have 
basically two update methods: double buffered (draw to an off-screen buffer, 
which is later made visible), and dirty rectangles (draw directly to the 
visible screen buffer based on what's been dirtied). For the latter, the user 
can watch for screen-invalidation events and add the sections to a list of 
rectangles to draw. For the former, the user will supply a complete buffer on 
the next update which would clear up any dirty spot. This would allow for a 
nice all-around increase in speed (or retention of speed, in OpenGL's case), 
which would be negated by emulating a VRAM surface.