Chaque constructeur de calculatrices a conçu sa propre bibliothèque Python graphique permettant de contrôler les pixels de l'écran :
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...
- 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.
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
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.
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
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)
Téléchargements :
