Hi guys,

I am working on a simple video app on iOS. I use Allegro to display the decoded video frames. I found the al_lock_bitmap/al_unlock_bitmap pair is the bottleneck. Follow is the test code for the problem.

void main()
{
ALLEGRO_DISPLAY *display = NULL;
ALLEGRO_BITMAP *bitmap = NULL;

al_init();

display = al_create_display(1136,640);

al_set_new_bitmap_format(ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE);
bitmap = al_create_bitmap(1136, 640);

double t1 = al_get_time();
int n = 128;

while( n > 0 )
{
ALLEGRO_LOCKED_REGION* lr = al_lock_bitmap(bitmap, al_get_bitmap_format(bitmap), ALLEGRO_LOCK_WRITEONLY);
/*
For demonstration purchase, I place nothing here.
*/
al_unlock_bitmap(bitmap);

al_set_target_backbuffer(display);
al_clear_to_color(al_map_rgb(0,0,0));

al_draw_bitmap(bitmap, 0, 0, 0);

al_flip_display();

printf("frame: %d\n", 128-n);
n--;
}

al_destroy_bitmap(bitmap);
al_destroy_display(display);

double t = al_get_time() - t1;
printf("FPS = %f\n", 128/t);

}

On my iPhone 5, I got FPS = 4.828641. What's the problem?

And by that, he means use this function:

https://www.allegro.cc/manual/5/al_lock_bitmap_region

You should really use Allegro 5.1 with the video streaming add-on. Then Allegro will provide you with the active frame though al_get_video_frame. This will be much faster than trying to do it by hand.

http://alleg.sourceforge.net/a5docs/refman/video.html
http://sourceforge.net/p/alleg/allegro/ci/5.1/tree/examples/ex_video.c

Oh, I didn't know that the video add-on also uses locking, but it does make sense for quick rendering. In that case we'll have the "fun task" of figuring out what SFML does differently... :p

I thought this flag only had a meaning for Direct3D? Should be documented then.

I suspect that flag also has an effect on locking a texture, it wont download it when you don't ask it to explicitly.

I'm not sure if I wouldn't rather deprecate ALLEGRO_NO_PRESERVE_TEXTURE. In addition to the slowness if you ever modify the contents (like the 5 FPS instead of 55 FPS in this thread), it also means keeping a memory copy of every bitmap around.

But of course the possibility of losing all of your bitmap contents is quite bad as well - I almost can't believe there's no better way around it. Should check SDL2 and SFML and see how they solve the problem.

I thought that was some old, antiquated problem during the early days of videocard acceleration--back in the day, if you used ALT-TAB at any point your computer would freeze for ~15-30 seconds. It was actually common to see people play their games in "windowed mode" or even "windowless" (a window, full screen, without window borders/title/etc) just because it made ALT-TAB'ing faster, and less prone to crashes.

http://stackoverflow.com/questions/972299/best-practices-for-alt-tab-support-in-a-directx-app

Then again, it's apparently still a userspace problem:

http://www.rockpapershotgun.com/2008/05/12/a-lamention-for-alt-tab/

Yet supposedly, Direct9 and later is (almost) never supposed to dump your resources:

Yet we're talking OpenGL here, right? I always thought OpenGL handled the situation better.

The only information I see related to OpenGL losing anything is this:

Our Direct3D bitmaps are not managed by the driver (since we allow drawing to them), so that's why we need to do this manually.

For OpenGL, it's not an issue except the two GLES platforms I described above which apparently evict the bitmaps from memory when you minimize the application. This makes sense, to a certain extent, given how apps are not meant to be closed on mobile devices...

As an aside, does the the video add on already use ALLEGRO_NO_PRESERVE_TEXTURE? If not, it probably should.