I notice that if my iOS game hibernates for more than a few minutes (closed from the Home button) that when I resume, it seems like the event queue is not always notified of new touch events. Seems the longer I leave it in hibernation, the more likely it is to not respond to touches when I resume.

As far as I can tell, I am properly handling the switch in/out, acknowledging, etc (as well as handling display lost/found events.)

Background audio stream always resumes fine, and the screen displays the proper "paused game" graphics. Since I am not manually refiling my stream buffer, I'm not sure if the audio playing is evidence that the event queue is actually functioning or not. And since the paused graphic is drawn before the game actually yields to iOS, I'm not sure if that's just buffered graphics or if its actually processing redraw events either. Tonight I'll try drawing something dynamic to the screen to see if this is the case... but meantime...

When the display is switched out/in, should I detroy/recreate my event queue/sources? Are there any pitfalls in doing so?

I haven't played with code yet, just brainstorming what the problem might be and any potential solutions.

I had this problem at one point. You solution might work. What turned out to be the problem for me was timer events still ticking, so on resume the game pumped through thousands of them causing a long delay. You could either use al_flush_event_queue, or stop and restart the timers on pause/resume.

I'd suggest stopping anything and everything on pause. shouldn't need to destroy stuff, unless you want to be super memory friendly. or just free temp stuff on a low memory warning.

Ahhh Trent I definitely think you're onto something because sometimes if I just wait a while, it seems to come back (if I don't get impatient and end the task first.)

I guess my assumption was that events wouldnt be generated while it was in background. DOH!

Thomas: What do you mean by stopping? Unregistering the event sources?

Everything as far as my game's drawing/update processing is stopped on pause. I just wasn't aware that events would still be firing after the switch out.

I agree with Thomas, you should stop anything that might generate repeated events, mainly timers. I was just giving some options. I bet it's your timers though. Stop them on pause (al_stop_timer) and restart them after (al_start_timer.)

What Trent said. stop the timers. And if you have any secondary threads or other async tasks, try and pause or stop those as well. Unless its some background download you want to keep going.

Also consider al_pause_event_queue

I'm a big confused about what's happening here. I thought the app still functioned when minimized, it just couldn't draw?

There is no minimization... but you can do stuff in the background if you really want, but you generally don't want to. people will complain about power use.

Hence my question. Timer events should be firing off in the background, and, unless you purposefully do something, should be handled as normal. I don't get why they are backing up.

It depends how you write your program. You can do it so that what you said is true, but then you're wasting resources on a limited device. Here's an example of how this can happen:

if (event.type == ALLEGRO_EVENT_DISPLAY_HALT_DRAWING) {
    // some cleanup code here
    al_acknowledge_drawing_halt(display);
    while (true) {
        ALLEGRO_EVENT e;
        al_wait_for_event(display_event_queue, &e);
        if (e.event_type == ALLEGRO_EVENT_DISPLAY_RESUME_DRAWING) {
            break;
        }
    }
    al_acknowledge_drawing_resume(display, NULL);
    // reset as needed and continue
}

If you need to process stuff in the background this doesn't work, but it spares the (possibly insignificant, but not necessarily) processing of your logic. NOTE: I intentionally left the stop/start timer out to show the potential problem. Also I used a separate event queue for display events only so you're not processing the other events.

Which brings up a good point, why not just skip those events in that loop? You could do that and it wouldn't cost much of anything.

I see. I just make the timer events a nop in my app when it is switched out, so this issue didn't hit me.

Of course you can even save whatever cpu time that takes by just stopping the timer. The only events that you'll get after that are resume events. So your loop shouldn't even run till you get switched back to.

I think it's better to stop the timer. The app really shouldn't do anything at all besides wake up on the switch-in. Otherwise if you have 100 apps thinking like that (and since no app ever quits that is easily reached) you drain your batter just handling 6000 timer handles / second (each of them 60). It doesn't sound much, but it means the kernel has to do 6000 context switches and keep/reload code into memory just to handle the NOP timer events.

Maybe for a future app. Going through the pain of sending out a new version just to fix this minor issue isn't worth my time .

That's exactly the attitude that makes me want to try your app, don't you ever change it

Not doing iOS development out of my own volition, so see if I care .

Seriously, I was just curious why my app didn't hit this bug, then explained why... and everybody ganged up on me because I'm this evil person who decreases their battery life by 0.1%. Obviously I didn't do it on purpose, but it's obvious that this isn't really an issue either. If you care that much, amend the bloody iOS readme and documentation for the display halted event to explain the best practices for it.