[…]
[…]
Euh, je vais peut être dire une connerie, mais pour que GD ne se bloque pas si l’aperçu plante, étant donné que l’aperçu est géré par la SFML, il suffit d’utiliser un sf::Thread non? sfml-dev.org/documentation/1.6/c … Thread.php
Vu qu’un Thread, c’est considéré comme un sous programme, normalement, si il plante, ça ne shoot pas GD 
Je fais la même chose avec QThread quand j’ai des sous fenêtres qui risquent d’être beaucoup utilisées.
Oui, mais c’est pas simple vu que le rendu est dans la même fenêtre que le reste.
Le mieux reste que GD ne plante pas.
Je déclare donc ouverte la chasse aux bugs ! 
[…]
Le principe d’IML a quand même pour inconvénient d’alourdir le code en introduisant des vérifications qui ne sont normalement pas nécessaires, et de dégrader les performances de l’application, ce qui peut s’avérer très sensible notamment au niveau des performances des jeux créés avec GD.
C’est déjà la cas, mais si il m’est arrivé d’oublier de vérifier les entrées dans certaines boites de dialogues, je veux bien des exemples précis pour que je puisse corriger ça.
Il me semble que j’utilise GDB correctement et qu’il faut quand même reconnaitre que le programme est assez capricieux dès qu’on s’éloigne des tutoriels de bases.
( Et puis, l’utilisation que je fait de GDB reste anecdotique : Le principal est que j’arrive à corriger les bugs. )
Dans tous les cas, ça reste une solution pratiquement “post mortem”. On arrête le programme avant qu’il ne crashe, mais on ne peut plus rien faire a part récupérer les dernières fonctions appelées ( ça reste déjà bien ) et dire “Désolé” à l’utilisateur.
Voilà.
[…]