Comprender la necesidad de las señales de Android VSYNC

Estoy tratando de obtener una mejor comprensión del subsistema de pantalla de Android, pero un elemento que todavía me está confundiendo es cómo se manejan las señales VSYNC, y por qué existen tantas en el primer lugar.

Android está diseñado para utilizar VSYNC en su núcleo, pero hay varias señales VSYNC que emplea. A través de https://source.android.com/devices/graphics/implement.html en la sección "Offset VSYNC", hay un diagrama de flujo que diagrama tres señales VSYNC: HW_VSYNC_0, VSYNC y SF-VSYNC. Entiendo que HW_VSYNC se utiliza para actualizar la sincronización en DispSync, y que VSYNC y SF-VSYNC son utilizados por las aplicaciones y el surfaceflinger, pero ¿por qué son necesarias estas señales individuales? Además, ¿cómo afectan las compensaciones a estas señales? ¿Hay un diagrama de tiempo disponible en cualquier lugar que mejor explica esto?

Gracias por cualquier ayuda que pueda ofrecer.

Para entender esto, lo mejor es comenzar con el documento de arquitectura de gráficos de nivel de sistema , teniendo en cuenta la sección Necesidad de Triple Buffer y el diagrama asociado (que idealmente sería un GIF animado). La frase que comienza, "Si la aplicación comienza a representar a medio camino entre las señales VSYNC" está hablando específicamente de DispSync. Una vez que hayas leído eso, espero que la sección DispSync del gráfico de los dispositivos doc tenga más sentido.

La mayoría de los dispositivos no tienen desplazamientos DispSync configurados, por lo que sólo hay una señal VSYNC. En lo que sigue supongo que DispSync está habilitado.

El hardware sólo proporciona una señal VSYNC, correspondiente a la actualización de la pantalla primaria. Los otros son generados en software por el código SurfaceFlinger DispSync, disparando a compensaciones fijas desde el VSYNC real. Algunos software inteligente se utiliza para evitar que los tiempos se deslicen fuera de fase.

Las señales se utilizan para activar la composición de SurfaceFlinger y la renderización de aplicaciones. Si sigue la sección del documento de arquitectura, puede ver que esto establece dos marcos de latencia entre cuándo la aplicación procesa su contenido y cuándo aparece el contenido en la pantalla. Piense en ello de esta manera: dado tres ocurrencias de VSYNC, la aplicación dibuja en V0, el sistema hace la composición en V1, y el cuadro compuesto se envía a la pantalla en V2.

Si está intentando realizar un seguimiento de la entrada táctil, tal vez moviendo un mapa por debajo del dedo del usuario, cualquier latencia será vista por el usuario como una respuesta táctil lenta. El objetivo es minimizar la latencia para mejorar la experiencia del usuario. Supongamos que retrasamos ligeramente los eventos, por lo que la aplicación se basa en V0.5, se compone en V1.2, y luego se cambia a la pantalla en V2. Al compensar la aplicación y la actividad SF, reducimos la latencia total de 2 cuadros a 1,5, como se muestra a continuación.

Introduzca aquí la descripción de la imagen

Para eso es DispSync. En el diagrama de retroalimentación de la página que enlazó, HW_VSYNC_0 es la actualización de hardware para la presentación física, VSYNC hace que la aplicación se procese y SF_VSYNC hace que SurfaceFlinger realice la composición. Refiriéndose a ellos como "VSYNC" es un poco inapropiado, pero en un panel LCD que se refiere a algo como "VSYNC" es probablemente un nombre incorrecto.

Las "marcas de fecha de vencimiento de la jubilación" que se indican en el diagrama de bucle de realimentación se refieren a una optimización inteligente. Puesto que no estamos haciendo ningún trabajo en el hardware real VSYNC, podemos ser un poco más eficientes si desactivamos la señal de actualización. El código DispSync usará las marcas de tiempo de las vallas de retirada (que es una discusión completa) para ver si está cayendo fuera de sincronización y volverá a habilitar temporalmente la señal de hardware hasta que vuelva a la pista.

Editar: puede ver cómo se configuran los valores en el Nexus 5 boardconfig . Tenga en cuenta los ajustes para VSYNC_EVENT_PHASE_OFFSET_NS y SF_VSYNC_EVENT_PHASE_OFFSET_NS .

  • Cómo configurar mi aplicación sms por defecto en Android Kitkat?
  • Desconexión del dispositivo BLE con el dispositivo Android automáticamente. Android BLE
  • El constructor de vista personalizada en Android 4.4 se bloquea en Kotlin, ¿cómo arreglarlo?
  • Problemas de compatibilidad de interfaz de usuario entre diferentes versiones de API
  • 4.4.4 no está en el gestor SDK de Android
  • Android: la barra de calificación no es visible, sólo se hace visible al tocarla
  • Android KitKat securityException al intentar leer de MediaStore
  • TWO_SWIPE_DOWN TAP no puede capturar en Google Glass GDK (XE16)
  • El controlador onScaleChanged de WebView se llama varias veces
  • Configuración de la barra de navegación como transparente y atenuada al mismo tiempo
  • Obtener la altura del teclado en Lollipop
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.