I have a few questions for using multiple windows.

1) What is the best way to avoid context switching?

2) Is it just video bitmaps that are attached to a display?

3) What happens when you draw images to a display that aren't attached to them? Is this supported?

4) Will al_convert_bitmap be backported to Allegro 5.0.x? Or should I just stick with A5.1?

Since only video bitmaps are stored in V-RAM, my guess is "yes". At least memory bitmaps I can't imagine being display dependent.

I think I once did that in a multi-threaded application without knowing. I loaded graphics in a thread that did not create the active display and then displayed them, anyways. I didn't experience any problems, but I also have to say that my engine wasn't really too far at that time (only a few tiny graphics on-screen) and that I don't know if it would work the same way when having multiple windows.

Drawing bitmaps to a display that aren't attached to that display treats them as memory bitmaps. It might actually be a bit worse than that, since it probably has to lock and read the contents from the source, then lock and write to the destination.

It is not an optimal route to go. You can however clone all of the bitmaps you want to use on both displays, so load them attached to one display, switch to the other display, and al_clone_bitmap the "shared" bitmaps.

A bit of background. An Allegro display always has its own rendering context (in OpenGL terms). The texture underlying a video bitmap belongs to a rendering context. This is where the concept of a video bitmap being "tied" to a display comes from.

On X, OpenGL contexts always share resources so, actually, you can draw a video bitmap in a different context. On Windows, OpenGL rendering contexts do NOT share by default. It is possible to create a context which shares with another, but Allegro does not expose this yet.

If al_is_compatible_bitmap returns true then it would draw with acceleration. Otherwise it is treated as a memory bitmap - but I'm a bit hazy on that point, as that would imply we have a memory copy of every video bitmap. Maybe NO_PRESERVE_TEXTURE has something to do with it.

No.

I think we only have a copy of every bitmap when the platform port doesn't default to preserving textures (ie X11+GL since it keeps the textures for us).

Will there be a al_convert_font function in 5.1.x? It would be cool if there was. That way you could load fonts in other threads and then convert them later.

How much work would this take?

I think for TTF fonts objects we would need to add a function to explicitly cache certain glyphs, for that to be useful.

A few times, I wish TTF font objects had separate caches per (compatible) target, so you don't need two of the "same" ALLEGRO_FONT to draw to memory and video bitmap targets. Not sure how it would work out, though.

Don't know, but probably not that much. The relevant function is wglCreateContextAttribsARB. I think it will mostly require testing.