[AD] No more video/system bitmaps

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

Title: No more video/system bitmaps

Here's a strawman proposal for Allegro 4.3: Getting rid of the different types of bitmaps.

Allegro programs shouldn't have to worry about which types of bitmap need to be used to run fast under which environment. It's silly to have to say "don't use video bitmaps if you want to blend, except if you use AllegroGL". This is going to be doubly true when we get another good hardware-accelerated driver. Also, I have yet to see anyone use system bitmaps effectively.

Instead, I propose the API have only one type of bitmap: The Bitmap.

Allegro would keep internal counters of the usage of the bitmap. If the bitmap is never read, or not read after a "long time", then it's automagically promoted to video bitmap on some allegro_flip() call. Conversely, if a video bitmap is needed for many SW operations, then it gets demoted to a memory bitmap.

Vertex Buffer Objects use a similar mechanism. There are some additional hints provided by the VBO API so we can select the best place to initially allocate the vertex buffer, but after that, the VBO can move from one memory region to another based on usage. VBOs can even live in *two* regions if (for example) it's read a lot by user applications (but never written), and is used to draw stuff very often.

System bitmaps should only be used when the driver supports accelerating them && when there is no more video memory to store video bitmaps. In OpenGL, there will never be system bitmaps.

I propose this modification to al_create_bitmap(): Remove the "type" parameter, and add a "usage" parameter. The usage parameter is logically an enum from the list {AL_STATIC_DRAW, AL_STATIC_READ, AL_DYNAMIC_DRAW, AL_DYNAMIC_READ, AL_STREAM_DRAW, AL_STREAM_READ}.

"Static" means the image does not change after being defined.

"Dynamic" means the image does change often.

"Stream" means the image will not be used often after it was defined (for example, for temporary bitmaps).

"Read" means the application will perform reads on the bitmap via al_acquire_region().

"Draw" means the application will not perform reads on the bitmap via al_acquire_region() (other reads are OK).

Buffers cannot migrate from one region to another within a frame (or while they're acquired). They can only move in al_display_flip().

Of course, it's entirely possible to create a contrived case where the buffer is always in the "wrong" region. For example, do many SW blends in odd frames, then do many many draws that are normally accelerated in even frames. AL would want to move the buffer around every frame.

We could make it more intelligent about those cases, but I'd like to think that in general, Applications tend to have more inter-frame coherency.

Comments/Suggestions/Flames?