Chaque constructeur de calculatrices a conçu sa propre bibliothèque
Python graphique permettant de contrôler les pixels de l'écran :
- kandinsky sur NumWorks
- casioplot sur Casio Graph 90/35+E II
- ti_graphics sur TI-83 Premium CE Edition Python
- ti_draw sur TI-Nspire CX II
C'est à dire que quand tu choisis de développer un script
Python pour l'une de ces bibliothèques, il sera alors incompatible avec tous les autres modèles.
A moins de t'embêter à publier une édition différente de ton script pour chaque modèle existant ou à venir...
Mais il existe toutefois une solution que nous t'avons concoctée,
PPN, pour
PolyPyNet (abrégé du français PolyPythonnettes), une bibliothèque pour les unifier toutes !
Non non, il ne s'agit absolument pas d'une bibliothèque graphique supplémentaire à apprendre, c'est justement ce que nous souhaitions éviter.
C'est en fait une bibliothèque de compatibilité. C'est ultra simple à utiliser pour toi, que tu sois utilisateur ou développeur :
- Utilisateur, il te suffit de charger les fichiers de PPN sur ta calculatrice et c'est tout, plus besoin de t'en occuper.
- Développeur, tu as juste à remplacer le nom de module graphique constructeur dans tes lignes d'importation par ppn et c'est tout, rien d'autre à changer dans ton script, tu continues à coder avec les fonctions de ta bibliothèque graphique préférée, que ce soit casioplot, kandinsky ou ti_graphics.
Nous te publions aujourd'hui une nouvelle illustration des capacités de
PPN. Voici une animation de battements de cœur codée initialement en
Python par
Hackcell pour
Casio Graph 90+E, et donc exploitant la bibliothèque graphique
casioplot.
Codée à l'occasion du
concours de démo graphiques en Python par
Planète Casio.
Et bien il suffit de remplacer comme indiqué la ligne d'importation
from casioplot import * par
from ppn import *, et ça marche direct sur tous les autres modèles couleur
NumWorks,
TI-83 Premium CE Edition Python et
TI-Nspire Ndless sans avoir à rien toucher d'autre !
Certes les définitions d'écran sont différentes et tout ne peut pas être adapté automatiquement. Mais si tu codes pour la bibliothèque
PPN tu pourras récupérer automatiquement les dimensions de l'écran de la plateforme exécutant ton script en appelant après importation les variables
ppn_w et
ppn_h, et en tenir compte.
Mais à ce détail près, c'est quand même impressionnant d'avoir un script aussi conséquent qui tourne sur toutes les machines après s'être seulement donné la peine de changer une simple ligne d'importation !
Parlons un petit peu performances. Précisons que les scripts utilisant
PPN ne permettent pas de réaliser de classement pertinent. En effet, un même appel graphique n'est en interne pas exécuté de la même façon selon le modèle utilisé :
- redirection directe vers la fonction graphique constructeur si le script est exécuté sur la plateforme pour laquelle il a été initialement développé, ou si la plateforme d'exécution dispose d'un appel natif équivalent
- passage à travers une ou plusieurs fonctions de compatibilité dans le cas contraire
C'est-à-dire qu'ici la
Casio Graph 90+E est privilégiée.
Mais ce n'est pas une raison pour ne pas te dire ce que ça donne, pour 1 battement de cœur complet :
- 1.665s : NumWorks N0110
- 2.228s: NumWorks N0110 (firmware tiers Omega)
- 2.751s : Graph 90+E
- 2.838s : NumWorks N0100 (firmware tiers Omega)
- 2.853s : NumWorks N0100
- 7.087s : TI-Nspire CX CR4+
- 9.142s : TI-Nspire CX CR3-
- 19min45.846s : TI-83 Premium CE Edition Python
On retrouve le problème
déjà évoqué pour la
TI-83 Premium CE Edition Python, à savoir que le
Python tourne sur un coprocesseur, et que toute instruction graphique génère un lourd événement de rafraîchissement qui doit transiter par le processeur principal avant d'atteindre le contrôleur écran, ce qui induit une latence très significative à chaque appel graphique.
Comme ici l'animation du cœur travaille avec des boucles de
set_pixel, le code équivalent est sans surprise catastrophique sur
TI-83 Premium CE Edition Python.
Il faudrait donc réduire significativement le nombre d'appels graphiques, et justement
Texas Instruments avait prévu le problème. Contrairement à la concurrence, sa bibliothèque
ti_graphics est tout sauf minimaliste. Elle comprend plein de fonctions dédiées permettant de remplacer de coûteuses boucles de
setPixel() pour le tracé de certaines primitives et formes géométriques, ne faisant donc transiter à la différence qu'un unique événément de rafraîchissement :
- lignes
- lignes brisées
- polygones avec remplissage optionnel
- rectangles avec remplissage optionnel
- arcs de cercles ou cercles avec remplissage optionnel
- arcs d'ellipses ou ellipses vec remplissage optionnel
- images
En attendant mieux nous avons donc la solution manuelle de sortir pour chaque script graphique
Python une version dédiée tout spécialement optimisée pour
TI-83 Premium CE Edition Python.
Il suffit de remplacer les boucles de
set_pixel() par les appels graphiques correspondants si existants dans
ti_graphics.
Nous te l'avons donc fait, avec cette fois-ci un cadre d'affichage correspondant bien à la zone graphique de 320×210 pixels de la
TI-83 Premium CE Edition Python.
Et bien la différence est impressionnante, plus que
45.483s pour un battement de cœur, soit une accélération d'un facteur de
54 !
- 1.665s : NumWorks N0110
- 2.228s: NumWorks N0110 (firmware tiers Omega)
- 2.751s : Graph 90+E
- 2.838s : NumWorks N0100 (firmware tiers Omega)
- 2.853s : NumWorks N0100
- 7.087s : TI-Nspire CX CR4+
- 9.142s : TI-Nspire CX CR3-
- 45.483s : TI-83 Premium CE Edition Python (script dédié optimisé à la main)
- 41min08.685s : TI-83 Premium CE Edition Python (compatibilité automatique PolyPyNet)
Un effort donc manuel certes, mais un effort qui vaudra largement le coût pour tes futurs scripts graphiques ! 
