Android 11 ajoute la prise en charge des appareils avec plusieurs taux de rafraîchissement. Cette fonctionnalité comporte trois composants principaux :
- Nouvelles API HAL introduites dans
android.hardware.graphics.composer@2.4
. - Code de plate-forme pour analyser les configurations d'appareil pour différents taux de rafraîchissement et définir le taux de rafraîchissement souhaité
- Nouvelles API SDK et NDK pour permettre aux applications de définir la fréquence d'images souhaitée
Mise en œuvre
Une prise en charge dédiée au changement de taux de rafraîchissement a été ajoutée à android.hardware.graphics.composer@2.4 HAL
. Nous vous recommandons fortement d'utiliser cette version car les versions précédentes de composer HAL ont une prise en charge limitée du changement de taux de rafraîchissement.
Groupes de configuration
Un nouvel attribut CONFIG_GROUP
a été ajouté à IComposerClient::Attribute
qui peut être interrogé à l'aide de l'API getDisplayAttribute_2_4
. Cet attribut permet aux fournisseurs de regrouper les configurations d'affichage. Les configurations dans le même groupe permettent une commutation transparente entre elles dans la plupart des cas. Le groupe de configuration est utilisé par la plate-forme pour différencier les configurations qui peuvent être commutées entre elles afin de changer le taux de rafraîchissement et non d'autres attributs pour une configuration.
Considérez l'exemple suivant qui démontre les avantages de l'utilisation de groupes de configuration avec un appareil prenant en charge quatre configurations d'affichage :
- 1080p à 60 Hz
- 1080p à 90 Hz
- 1080i à 72 Hz
- 1080i à 48 Hz
Même si l'appareil prend en charge les taux de rafraîchissement de 48 Hz, 60 Hz, 72 Hz et 90 Hz, l'écran fonctionne dans un mode différent et le passage de 60 Hz à 72 Hz modifie la configuration de l'affichage de 1080p à 1080i, ce qui n'est peut-être pas le comportement souhaité. Ceci est résolu en utilisant des groupes de configuration. En regroupant 60 Hz et 90 Hz dans un groupe de configuration et 48 Hz et 72 Hz dans un autre groupe de configuration. La plateforme sait qu'elle peut basculer entre 60 Hz et 90 Hz et entre 48 Hz et 72 Hz mais pas entre 60 Hz et 72 Hz car cela entraînera un changement de configuration plutôt que de simplement changer le taux de rafraîchissement.
![](https://source.android.com/static/docs/core/graphics/images/multiple-refresh-rate-green.gif?authuser=5&hl=fr)
![](https://source.android.com/static/docs/core/graphics/images/multiple-refresh-rate-blue.gif?authuser=5&hl=fr)
Mises à jour de l'API du compositeur
- getDisplayVsyncPeriod
- Pour un meilleur contrôle et une meilleure prévisibilité lors de la modification des taux de rafraîchissement,
getDisplayVsyncPeriod
a été ajouté.getDisplayVsyncPeriod
renvoie le taux de rafraîchissement actuel (en termes de période vsync) auquel l'affichage fonctionne. Ceci est particulièrement utile lorsque la transition entre le taux de rafraîchissement et le taux de rafraîchissement actuel est nécessaire à la plate-forme pour décider quand démarrer l'image suivante. - setActiveConfigWithConstraints
- La méthode
setActiveConfigWithConstraints
est une nouvelle extension de la méthodesetActiveConfig
existante et fournit plus d'informations sur la modification de la configuration. Les contraintes sont fournies dans le cadre des paramètresvsyncPeriodChangeConstraints
et contiennent les paramètres suivants. - désiréTimeNanos
- L'heure dans
CLOCK_MONOTONIC
après laquelle la période vsync peut changer (c'est-à-dire que la période vsync ne doit pas changer avant cette heure). Ceci est utile lorsque la plate-forme souhaite planifier à l’avance un changement de taux de rafraîchissement mais qu’elle a déjà des tampons dans la file d’attente à présenter. La plate-forme définit cette durée en conséquence pour tenir compte de ces tampons et s'assurer que la transition du taux de rafraîchissement sera aussi fluide que possible. - transparentObligatoire
- Si cela est vrai, cela nécessite que le changement de période de vsync se produise de manière transparente, sans artefact visuel notable. Cet indicateur est utilisé par la plateforme lorsqu'un changement de taux de rafraîchissement est nécessaire à la suite d'un changement de contenu (par exemple, l'appareil est inactif et l'animation démarre). Cela donne au fournisseur la possibilité de ne pas autoriser certaines modifications de configuration lorsqu'elles pourraient entraîner un artefact visuel visible. Si les configurations ne peuvent pas être modifiées de manière transparente et que
seamlessRequired
est défini surtrue
, l'implémentation devrait renvoyerSEAMLESS_NOT_POSSIBLE
comme code de retour et appeler le nouveau rappelonSeamlessPossible
lorsque le même changement de configuration peut être effectué de manière transparente. En cas de succès, l'implémentation renvoie un
VsyncPeriodChangeTimeline
qui indique à la plate-forme quand s'attendre à ce que le changement de taux de rafraîchissement se produise. Les paramètresnewVsyncAppliedTimeNanos
doivent être définis sur l'heure dansCLOCK_MONOTONIC
à laquelle le nouvel affichage commencera à s'actualiser à la nouvelle période vsync. Ceci, associé àdesiredTimeNanos
, permet à la plate-forme de planifier à l'avance le changement de taux de rafraîchissement et de commencer à cocher les applications pour le nouveau taux de rafraîchissement à l'avance. Cela permet une transition transparente du taux de rafraîchissement.Certaines implémentations nécessitent l'envoi d'une trame de rafraîchissement avant que le taux de rafraîchissement puisse être envoyé. Pour cela, le HAL a le paramètre
refreshRequired
pour indiquer qu'une trame de rafraîchissement est nécessaire etrefreshTimeNanos
pour indiquer le premier vsync après lequel une trame de rafraîchissement doit être envoyée.- onVsyncPeriodTimingChanged [rappel]
- Un nouveau rappel qui peut être appelé par le HAL pour indiquer à la plateforme qu'un paramètre de la chronologie a changé et que la plateforme doit ajuster sa chronologie. Ce rappel devrait être appelé si, pour une raison quelconque, l'ancienne chronologie a été manquée en raison d'un long temps de traitement sur HAL ou d'une trame d'actualisation tardive.
Comment la plateforme décide-t-elle de modifier le taux de rafraîchissement ?
La sélection du taux de rafraîchissement s'effectue dans les deux services système suivants :
- Gestionnaire d'affichage
- Le
DisplayManager
définit la politique de haut niveau autour du taux de rafraîchissement. Il définit une configuration d'affichage par défaut, qui est la même que la configuration du compositeur HAL. De plus, il définit une plage de valeurs minimales et maximales queSurfaceFlinger
peut choisir comme taux de rafraîchissement. - SurfaceFlinger
- Détermine le taux de rafraîchissement en définissant une configuration qui se trouve dans le même groupe de configuration que la configuration par défaut et avec un taux de rafraîchissement compris dans la plage min/max.
Le gestionnaire d'affichage exécute les étapes suivantes pour déterminer la stratégie :
- Recherche l'ID de configuration par défaut en interrogeant la configuration active depuis
SurfaceFlinger
- Restreindre la plage de valeurs minimales et maximales en itérant sur les conditions du système
- Paramètre de taux de rafraîchissement par défaut : la valeur du taux de rafraîchissement par défaut est définie dans la superposition de configuration
R.integer.config_defaultRefreshRate
. Cette valeur est utilisée pour déterminer le taux de rafraîchissement standard de l'appareil pour les animations et les interactions tactiles. - Paramètre du taux de rafraîchissement maximal : la valeur du taux de rafraîchissement maximal est lue à partir de
Settings.System.PEAK_REFRESH_RATE
. Cette valeur est modifiée au moment de l'exécution pour refléter le paramètre actuel de l'appareil (par exemple à partir d'une option de menu). La valeur par défaut est définie dans la superposition de configurationR.integer.config_defaultPeakRefreshRate
. - Paramètre du taux de rafraîchissement minimum : la valeur du taux de rafraîchissement minimum est lue à partir de
Settings.System.MIN_REFRESH_RATE
. Cette valeur peut être modifiée au moment de l'exécution pour refléter le paramètre actuel de l'appareil (par exemple à partir d'une option de menu). La valeur par défaut est 0, il n'y a donc pas de minimum par défaut. - Application demandée ModeId : les applications peuvent définir
WindowManager.LayoutParams.preferredDisplayModeId
pour refléter une configuration préférée avec laquelle l'affichage doit fonctionner. Dans la plupart des conditions,DisplayManager
définit l'ID de configuration par défaut en conséquence et définit les taux de rafraîchissement minimum et maximum pour qu'ils correspondent au taux de rafraîchissement de la configuration. - Économiseur de batterie : le taux de rafraîchissement est limité à 60 Hz ou moins lorsque l'appareil est en mode faible consommation, ce qui est indiqué via
Settings.Global.LOW_POWER_MODE.
- Paramètre de taux de rafraîchissement par défaut : la valeur du taux de rafraîchissement par défaut est définie dans la superposition de configuration
Une fois que DisplayManager
a défini la politique, SurfaceFlinger
définit le taux de rafraîchissement en fonction des couches actives (couches qui mettent en file d'attente les mises à jour des images). Si le propriétaire de la couche définit une fréquence d'images , SurfaceFlinger essaie de définir la fréquence de rafraîchissement sur quelque chose qui est un multiplicateur de cette fréquence. Par exemple, si deux couches actives définissent leur fréquence d'images sur 24 et 60, SurfaceFlinger choisira 120 Hz si elle est disponible. Si un tel taux de rafraîchissement n'est pas disponible pour SurfaceFlinger, il essaiera de choisir le taux de rafraîchissement qui présente l'erreur minimale pour la fréquence d'images. Pour plus d'informations, consultez la documentation du développeur sur developer.android.com
SurfaceFlinger
gère les indicateurs suivants pour contrôler la manière dont le taux de rafraîchissement est décidé :
-
ro.surface_flinger.use_content_detection_for_refresh_rate:
s'il est défini, le taux de rafraîchissement est décidé en fonction des couches actives, même si aucune fréquence d'images n'a été définie. SurfaceFlinger maintient une heuristique dans laquelle il trouve le fps moyen que la couche publie dans les tampons en examinant l'horodatage de présentation attaché au tampon. -
ro.surface_flinger.set_touch_timer_ms
: si > 0, le taux de rafraîchissement par défaut sera utilisé lorsqu'un utilisateur touche l'écran pendant le délai d'expiration configuré. Cette heuristique est conçue pour être prête avec le taux de rafraîchissement par défaut pour les animations. -
ro.surface_flinger.set_idle_timer_ms
: si > 0, le taux de rafraîchissement minimum sera utilisé lorsqu'il n'y a pas de mise à jour d'écran pendant le délai d'expiration configuré. -
ro.surface_flinger.set_display_power_timer_ms
: si > 0, le taux de rafraîchissement par défaut sera utilisé lors de l'allumage de l'écran (ou lors de la sortie de l'AOD) pendant le délai configuré.
API de fréquence d'images
L'API de fréquence d'images permet aux applications d'informer la plate-forme Android de leur fréquence d'images prévue et est disponible sur les applications qui ciblent Android 11. Pour en savoir plus sur l'API de fréquence d'images, consultez la documentation du développeur sur Developer.android.com .
Options de développeur
![](https://source.android.com/static/docs/core/graphics/images/multiple-refresh-rate-toggle.gif?authuser=5&hl=fr)
Une nouvelle option de développeur a été ajoutée au menu qui active une superposition sur l'écran avec le taux de rafraîchissement actuel. La nouvelle option se trouve sous Paramètres > Système > Options du développeur > Afficher le taux de rafraîchissement.