La raison pour laquelle je lui avais écrit était que la version d'ExtGraph embarquée dans GTC était vieille, mais que les versions plus récentes sont beaucoup moins adaptées à la programmation on-calc, vu le nombre élevé de fonctions.
Pour pouvoir mettre ExtGraph à jour, il faut donc faire un découpage (que j'ai plus ou moins mis sur la todo list, parce que je vois bien que le header extgraph.h fait maintenant 'juste' ~170 KB, dont au moins 50 KB de commentaires Doxygen pour remplacer l'inmaintenable documentation telle qu'elle était faite auparavant).
Pollux m'a fait la remarque qu'il fallait faire un meilleur découpage qu'un découpage thématique, bonne remarque.
Dans la discussion sur la taille qu'ExtGraph 2.00 Beta 5 (+ fixes & améliorations) prend, j'ai écrit:
Je n'ai jamais fait l'estimation exacte, mais 128 KB me paraissent être un ordre de grandeur plausible pour code + relocations. En tout cas, 64 KB est sensiblement trop faible.
* extgraph.a, certes sous un format de stockage pas super compact, et intégralement (sauf erreur) compilé avec --all-relocs, fait actuellement 412598 octets. Une réduction à 128 KB voudrait dire que deux octets sur trois dans le .a ne sont pas du code + relocations.
* 128 KB pour 512 fonctions (il y en a un peu moins, mais on va simplifier ^^) font 256 octets en moyenne par fonction, soit 128 instructions de 2 octets ou 64 instructions de 4 octets. Sans compter les relocations.
Beaucoup de routines sont plus petites, mais nombre de routines de sprite grayscale (en particulier les clippées) sont plus grosses.
La philosophie "1 routine plus optimisée pour un format donné et un mode de dessin donné" d'ExtGraph, permise par l'approche lib statique, coûte en place
Depuis longtemps dans SVN, et depuis cet été avec la release, enfin, de 2.00 Beta 5, la licence d'ExtGraph est devenue duale:
* licence TICT classique (peu de restrictions, si ce n'est l'interdiction de l'usage commercial); * LGPL + exception de redistribution en forme binaire non modifiée.
