Android develompment: "Locking non-backbuffer WRITEONLY" delays start 20 seconds


I'm trying to run my game in a Android device (LG-G6) and we got two problems:

- First, but less important, when I call al_get_display_mode it returns a NULL pointer. I used this call on PC to get the fullscreen resolution. In Android I just commented out, and they get the proper resolution automatically (maybe because AllegroActivity, I don't know really).

- My second, and annoying problem is application start time. The application runs smoothly all the time, but when start, it took like 22 seconds to show the first image. In logcat I can see the delay is betwen this calls (no code skkiped betwen them):

107-17 11:52:41.144 27011-27049/ I/allegro: opengl D 27049: ogl_lock_es.c:259 ogl_lock_region_nonbb [ 0.28942] Locking non-backbuffer WRITEONLY 207-17 11:53:03.430 27011-27049/ I/allegro: opengl D 27049: ogl_lock_es.c:591 ogl_unlock_region_nonbb_2 [ 22.57591] Unlocking non-backbuffer (non-FBO)

This happens in debug or release modes.

Any help is appreciated :-*

Edgar Reynaldo

I can't tell you why it takes 20 seconds. It should only be uploading data, which shouldn't take 20 seconds. What are you doing with the data? Or is it allegro doing that?

Also, al_get_display_mode may not be implemented on Android


al_get_display_mode is not implemented for Android. IIRC, your display is automatically resized to fit the screen (via ALLEGRO_EVENT_DISPLAY_RESIZE, I think, so you should handle that).

Can you trace where the calls to ogl_lock_region_nonbb occur and what is actually done there?

André Silva

Is the bitmap a memory one, or a video one?



It was just a heavy bitmap loading... I was using TGA, and the tileset weight was arround 10MB. When I compressed the bitmap with PNG it just load fine. Anyway, It's normal a delay of 20 second to load a 10MB for mobile devices?

Sorry for not read the forum until now :/


To be clear, that 20 second delay is with TGA or PNG, or both?


Only with TGA. I solve the issue swapping to PNG.

Thread #616971. Printed from