0

Currently I'm getting the following output in Logcat:

Excessive delay in unblankDisplay() while turning screen on: 237ms

This seems to trigger the OS destroying my window and attempting to recreate it, but my frame time doesn't seem to be anywhere near that long. Is there something else that I need to trigger to indicate that I've unblanked the display properly?

OvertCurrent
  • 35
  • 6

1 Answers1

0

That's just an advisory message. It's emitted from nativeUnblankDisplay() in android_view_SurfaceControl.cpp (line 406).

(The code is non-obvious -- ALOGD_IF_SLOW creates an object on the stack that checks the time in the constructor and the destructor. When the object goes out of scope, i.e. when this function returns, the destructor checks to see if too much time has elapsed, and logs a message if it has.)

The unblankDisplay() call is making an IPC request to SurfaceFlinger, which forwards it to the hardware composer (if one exists).

fadden
  • 51,356
  • 5
  • 116
  • 166
  • Hmmm... In that case, would you know what would cause this messaging to be sent up when I resume? 'E/BufferQueue( 177): [com.ace.engine/android.app.NativeActivity] dequeueBuffer: BufferQueue has been abandoned! W/Adreno200-EGLSUB( 8167): : dequeue native buffer fail: No such device W/Adreno200-ES20( 8167): : GL_OUT_OF_MEMORY W/Adreno200-EGL( 8167): : EGL_BAD_ALLOC W/Adreno200-EGL( 8167): : EGL_BAD_SURFACE' – OvertCurrent Feb 19 '14 at 00:54
  • `BufferQueue` has a producer side and a consumer side. The consumer has abandoned the queue, so the producer side is failing. The `BufferQueue` underlies the EGL surface, so the rest of the messages are just GL/EGL trying to say "I can't get a buffer to draw on" using whatever error codes are handy. I'm assuming that the consumer here is SurfaceFlinger (the system graphics compositor). Sounds like the window manager is discarding your surface. Does your code work if you change the device orientation? – fadden Feb 19 '14 at 01:10
  • No, we haven't handled orientation changes, we are locked to landscape orientation. That does seem to match what is happening however. My current issue in code is that when I resume an application, I flag that it's okay to render on my other thread, but then shortly after I start a render, the window is destroyed. – OvertCurrent Feb 19 '14 at 01:32
  • Are you getting `APP_CMD_TERM_WINDOW`? I haven't worked with `NativeActivity` before, but it looks like you should be getting a TERM_WINDOW / INIT_WINDOW pair. – fadden Feb 19 '14 at 01:55
  • I hadn't yet, the thread was blocked waiting for the opportunity to send that command/the render thread was waiting for an event to finish to run. – OvertCurrent Feb 19 '14 at 02:19