Obtener un ANativeWindowBuffer de ANativeWindow_Buffer

Para obtener acceso rápido a píxeles de textura de OpenGL ES 2.0 en Android NDK, quiero usar la extensión eglCreateImageKHR() .

De acuerdo con la documentación EGL_NATIVE_BUFFER_ANDROID :

Esta extensión permite usar un búfer de ventana de Android (struct ANativeWindowBuffer ) como una fuente EGLImage .

ANativeWindowBuffer es una struct interna utilizada por las clases de framework nativas como GraphicBuffer . Desafortunadamente, ya que estoy en NDK no tengo acceso directo a estas clases.

El NDK native_window interfaz me permite pasar un objeto de Surface Java a través de la NDK. Puedo entonces utilizar ANativeWindow_fromSurface() para conseguir una manija ANativeWindow* opaca. Con este puntero puedo llamar ANativeWindow_lock() para rellenar una estructura del tipo ANativeWindow_Buffer ( ANativeWindow_Buffer el _ ).

Si intento utilizar este &ANativeWindow_Buffer objeto con eglCreateImageKHR() falla con EGL_BAD_NATIVE_WINDOW .

Mi pregunta es: ¿Cómo puedo utilizar ANativeWindow_Buffer con eglCreateImageKHR() o, alternativamente, cómo obtener un ANativeWindowBuffer de ANativeWindow_Buffer o de ANativeWindow* .

De lo que descubrí al pasar por este camino, ANativeWindow_Buffer y ANativeWindowBuffer son tipos completamente diferentes. Bueno, son algo similares, pero definitivamente tan diferentes que no se pueden usar de forma intercambiable.

Si desea comparar, aquí están las definiciones:

Usted notará que tienen algunos campos en común ( width , height , stride , format ). La gran diferencia es que ANativeWindow_Buffer contiene un puntero a los datos reales, mientras que ANativeWindowBuffer contiene un identificador opaco del tipo buffer_handle_t .

Así que si usted descubrió cómo obtener un ANativeWindow_Buffer , y esperaba que usted estaba bien en su camino a un ANativeWindowBuffer , usted es … probablemente no. Al menos esa fue mi conclusión. Creo que los nombres muy similares son sólo una broma.

No encontré una manera de crear un ANativeWindowBuffer del código NDK. Al menos con el uso de sólo APIs compatibles, creo que no es posible. Mi investigación fue con KitKat.

  • JNI manteniendo una referencia global a un objeto, accediendo a ella con otros métodos JNI. Mantener un objeto C ++ activo en varias llamadas JNI
  • JNI: no se puede encontrar la biblioteca en java.library.path al ejecutar JUnit
  • Código java para leer la imagen en lugar de obtener el marco
  • Android JNI: GetObjectClass se bloquea con SIGSEGV (no es una referencia JNI válida)
  • No se encontró JNI_OnLoad en ... saltando init
  • Enviar cadena C ++ a Java a través de JNI
  • Pasar el puntero de C a Java se convierte en NULL
  • Cómo crear jni y Android.mk?
  • UnsatisfiedLinkError (Método nativo no encontrado)
  • Desbordamiento de ReferenceTable (máx = 512) JNI
  • La aplicación se bloquea al cambiar de actividad de cocos2d-x a otra actividad en Android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.