"(Ce message est aussi valable pour N. Boulay, qui depuis quelques années, à chaque news Linuxfr sur G'MIC en profite sur donner son avis sur la bonne façon de programmer. Depuis le temps, il aurait donc eu le temps de contribuer d'une manière ou d'un autre au projet pour nous remettre dans le "droit chemin", mais on a jamais eu de nouvelles, on attend toujours)."
Cela fait longtemps que je n'essayes plus de te convaincre. C'est ton projet, tu fais ce que tu veux. J'avais juste trouver génial la façon d'utiliser la lib pour faire du traitement d'image, et parfaitement horrible le code de la lib. D'ailleurs, je t'avais filé un mini patch qui a augmenté les perfs de 5 à 10% si je me rappelle bien.
Par exemple, la structure mémoire de l'image n'était pas un objet à part des traitements, il était ainsi impossible de changer le layout mémoire sans devoir réécrire tous les traitements. Je voulais tenter une organisation en "tile", voir rendre possible l’auto-vectorisation. Mais cela a été impossible à faire.
[^] # Re: color2gray et organisation du code
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 3.
Cela fait longtemps que je n'essayes plus de te convaincre. C'est ton projet, tu fais ce que tu veux. J'avais juste trouver génial la façon d'utiliser la lib pour faire du traitement d'image, et parfaitement horrible le code de la lib. D'ailleurs, je t'avais filé un mini patch qui a augmenté les perfs de 5 à 10% si je me rappelle bien.
Par exemple, la structure mémoire de l'image n'était pas un objet à part des traitements, il était ainsi impossible de changer le layout mémoire sans devoir réécrire tous les traitements. Je voulais tenter une organisation en "tile", voir rendre possible l’auto-vectorisation. Mais cela a été impossible à faire.
"La première sécurité est la liberté"