Fréquence d'actualisation adaptative

Android 15 introduit la fonctionnalité de fréquence d'actualisation adaptative (ARR, Adaptive Refresh Rate), qui permet à la fréquence d'actualisation de l'écran de s'adapter à la fréquence d'images du contenu à l'aide d'étapes VSync discrètes.

La fonctionnalité ARR offre les avantages suivants :

• Réduction de la consommation d'énergie : par défaut, ARR permet aux appareils de fonctionner à des taux inférieurs à leur taux de rafraîchissement maximal, en passant à des taux plus élevés uniquement lorsque cela est essentiel pour l'expérience utilisateur, ce qui minimise la consommation d'énergie inutile.
• Réduction des saccades : ARR élimine le besoin de changer de mode, ce qui est une cause connue de saccades.

Présentation

Sur les panneaux non ARR, l'affichage est actualisé à une cadence fixe déterminée par le mode d'affichage actif.

Sur les panneaux ARR, la fréquence VSync et la fréquence d'actualisation de l'écran sont dissociées, ce qui permet aux fréquences d'actualisation de changer dans un mode d'affichage en fonction de la cadence de mise à jour du contenu. Les panneaux peuvent fonctionner à des fréquences d'actualisation qui sont des diviseurs de l'effet de déchirement (TE) du panneau. Les OEM peuvent implémenter l'ARR en fonction des compromis de puissance qu'ils préfèrent.

La figure suivante montre un écran avec une vsyncPeriod de 240 Hz et une minFrameIntervalNs (fréquence d'actualisation maximale) de 120 Hz. La synchronisation verticale se produit toutes les 4,16 ms. Une frame peut être présentée à n'importe quel multiple de la synchronisation verticale après la minFrameIntervalNs de la dernière frame.

Figure 1 : Exemple de RA annuel.

Implémentation

Android 15 est compatible avec ARR grâce aux nouvelles API HAL Hardware Composer (HWC) et aux modifications apportées à la plate-forme. Pour activer ARR, les OEM doivent prendre en charge les modifications du noyau et du système sur les appareils exécutant Android 15 ou version ultérieure, et implémenter la version 3 des API android.hardware.graphics.composer3, comme indiqué dans les sections suivantes.

Pour en savoir plus, consultez l'implémentation de référence de Pixel des API compatibles avec ARR.

Remarque : Le code source AOSP mentionne vrr en lien avec les éléments ARR.

DisplayConfiguration.aidl

L'API DisplayConfiguration.aidl spécifie la configuration de l'affichage à l'aide d'attributs d'affichage, ainsi que les attributs suivants pour ARR :

• Facultatif vrrConfig : Si cette option est définie, ARR est activé pour des configurations spécifiques. Si la valeur est définie sur null, le mode d'affichage est défini sur des modes non ARR tels que multiple refresh rate (MRR). Avec cet attribut, un affichage peut être configuré en tant que MRR ou ARR, mais pas les deux.

• vsyncPeriod : Fréquence VSync de l'écran. Sur les écrans ARR, cette valeur est utilisée pour dériver les fréquences d'actualisation discrètes compatibles.

  Les fournisseurs doivent définir la valeur DisplayConfiguration.vsyncPeriod pour tous les appareils. Pour les écrans non ARR, DisplayConfiguration.vsyncPeriod correspond à la fréquence d'actualisation de l'écran. Si un appareil est compatible avec 120 Hz, cette valeur doit être de 8,3 ms.

  Pour les affichages ARR, DisplayConfiguration.vsyncPeriod correspond à la fréquence du signal TE. Si un appareil a un minFrameIntervalNs de 8,3 ms, mais que la fréquence TE est de 240 Hz, cette valeur doit être de 4,16 ms.

VrrConfig.aidl

L'API VrrConfig.aidl inclut les attributs suivants :

• minFrameIntervalNs : taux d'actualisation maximal que l'écran peut prendre en charge.
• NotifyExpectedPresentConfig : cette valeur est déterminée par le moment où l'écran doit être averti à l'avance d'un prochain frame.

IComposerClient.notifyExpectedPresent fournit un indice pour un frame susceptible d'être présenté, afin que l'écran puisse adapter sa période d'autoréactualisation en conséquence. frameIntervalNs représente la cadence actuelle qui suit expectedPresentTime. Par exemple, si notifyExpectedPresent est appelé avec expectedPresentTime N et frameIntervalNs de 16,6 ms, le prochain frame se trouve à N + 16,6 ms après l'heure actuelle N. Après le moment actuel N, la cadence d'images est de 16,6 ms jusqu'à ce que d'autres modifications soient apportées.

IComposerClient.notifyExpectedPresent n'est appelé que lorsque DisplayConfiguration.notifyExpectedPresentConfig est défini et si l'une des conditions de timing suivantes se produit :

• Heure actuelle hors cadence : l'heure de présentation attendue du prochain frame s'écarte de la fréquence d'actualisation régulière de l'écran définie par frameIntervalNs.
• Délai avant expiration dépassé : l'intervalle de temps entre les images précédentes est supérieur ou égal à notifyExpectedPresentConfig.timeoutNs.

DisplayCommand.frameIntervalNs

DisplayCommand.frameIntervalNs fournit un indice sur la cadence des prochains frames en nanosecondes.

Tests

Utilisez onRefreshRateChangedDebug pour le débogage. Cette méthode informe le client que la fréquence d'actualisation de l'écran a changé.

Utilisez l'application de test TouchLatency pour les tests manuels, comme illustré à la figure 2 :

Figure 2. Application de test TouchLatency.

Dans l'application de test, utilisez le curseur pour ajuster la fréquence de rendu à différentes valeurs de taux d'actualisation du diviseur de la fréquence d'actualisation de l'écran. Observez comment la fréquence d'images change en fonction de la fréquence demandée.