Forum TI-Planet.org

Les dernières mises à jour 17.0 et 18.0 ont introduit des menus dans lesquels un texte de couleur gris est affiché sur un fond de couleur gris, suis-je le seul à trouver ça illisible ?



De même , j'observe un micro lag pas agréable en naviguant dans ce menu, comme vous pourrez le constater dans cette courte vidéo.

Là encore, suis je le seul à constater ce micro ralentissement ?
D'ailleurs la vidéo montre bien que le texte gris sur fond gris est peu lisible.

Effectivement, le menu devient moins visible une fois selectionné...
Le temps de latence est présent sur tous les menus ? (impossible pour moi de tester : je n'ai installé ni la v17 ni la v18).

fmo wrote:Effectivement, le menu devient moins visible une fois selectionné...
Le temps de latence est présent sur tous les menus ? (impossible pour moi de tester : je n'ai installé ni la v17 ni la v18).

Il est présent sur les menus conçus en deux blocs, le bloc de gauche contient le texte et le logo, le bloc de droite la flèche.

Très marqué ici aussi :


Je le vois également dans ces sous menus :



il est par contre non perceptible sur l'interface python ou fonction par exemple :

Le gris sur fond gris, ce n'est pas nouveau tu sais :


Donc c'est un changement de thème global qui serait nécessaire.

critor wrote:Le gris sur fond gris, ce n'est pas nouveau tu sais :


Donc c'est un changement de thème global qui serait nécessaire.

En effet, mais ce gris sur fond gris est caché, il n'est pas présent sur la première page de l'app.
C'est d'autant plus curieux que sur le reste de l'ergonomie / lisibilité il n'y a pas grand chose à redire.

Hello.
Sur les quelques images présentées:
- Les menus pour lesquels tu observes une réactivité moindre, contiennent tous une image.
- Les menus pour lesquels tu n'observes pas de problème ne contiennent que du texte.

Une piste ?

C'est surtout la construction du menu qui semble en cause.

Les menus textuels sont constitués d'un unique rectangle, qui est donc remplacé puis reconstruit, on ne voit pas le lag par découpage ni le scintillement du texte.

Les menus qui lags sont constitués de deux rectangles, une image, et en effet la construction de l'ensemble doit être suffisamment lent pour que l'on puisse observer le ralentissement.

La question est de savoir si je suis le seul à l'observer ou si d'autres peuvent reproduire ce fonctionnement.

La lenteur de l'affichage des calculatrices NumWorks est due à sa conception. Le contrôleur LCD est déporté et n'est accessible qu'à travers un bus externe lent. De plus, ce bus n'expose qu'un jeu de registres de contrôle, l'accès au framebuffer du contrôleur ne peut se faire qu'indirectement via des commandes. Pour des raisons d'usage de RAM, le firmware epsilon ne garde pas une copie de l'écran et toutes les commandes de dessin sont traités directement, hors le coût de mise en place d'une opération de mise à jour d'un rectangle de pixels n'est pas négligeable. Enfin, pour les opérations avec de l'alpha blending le firmware doit lire les pixels du framebuffer déporté avant d'écrire les nouvelles valeurs, ce qui est particulièrement lent.

Les calculatrices concurrentes tendent à avoir des contrôleurs LCD en interne dans leur microcontrôleur, où la mise à jour d'un pixel se résume à écrire des octets en mémoire car le framebuffer est directement mappé dans le bus de mémoire, ce qui est beaucoup plus rapide que la machine à gaz sur les calculatrices NumWorks pour faire une opération analogue.

Merci pour cette explication technique précise et détaillée.

Si je résume, il faut espérer qu'un prochain modèle ait un contrôleur LCD en interne où qu'ils renoncent à réécrire et changer de couleur de grands rectangles ? (plus le rectangle est grand, plus le lag est visible).

cent20 wrote:Si je résume, il faut espérer qu'un prochain modèle ait un contrôleur LCD en interne où qu'ils renoncent à réécrire et changer de couleur de grands rectangles ? (plus le rectangle est grand, plus le lag est visible).

C'est a peu près ça.

Au passage, changer un grand rectangle en une opération est moins coûteux que de changer la même surface en plusieurs opérations, une autre source de ralentissement ici est le rendu du texte qui se fait caractère par caractère dans epsilon (compromis entre consommation RAM, consommation Flash et compression des polices d'écriture), ce qui multiplie le nombre de rectangles à mettre à jour dans la vidéo initiale.

Il existe différente techniques pour palier aux problèmes de scintillement (certaines déjà démontrées par le firmware GESTE ou encore l'émulateur de NES), mais ce n'est pas un problème suffisamment sérieux pour justifier un effort d'optimisation logiciel dessus pour l'équipe NumWorks.

Par rapport au prochain modèle, la rumeur du N120 EX analysée dans viewtopic.php?f=97&t=25515 laisse penser que le microcontrôleur utilisé disposerait d'un contrôleur LCD intégré (ce n'est cependant pas une garantie qu'ils vont l'utiliser).