dialloa/SAE32_2025
Template
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Modifications apportés

Browse Source
This commit is contained in:
ANHDIRE
2026-01-03 13:08:16 +01:00
parent bceb70c052
commit 5cd5f4c044
34 changed files with 2566 additions and 2519 deletions
Download Patch File Download Diff File Expand all files Collapse all files
temp/learning-Log.txt
+49 -49
View File
@@ -1,50 +1,50 @@
Learning log – Problème de blocage de la fenêtre après la sauvegarde:
Après avoir implémenté la fonctionnalité d’export au format PIF depuis l’interface du convertisseur,
j’ai rencontré un problème important : une fois que je cliquais sur le bouton d’exportation,
la fenêtre se figeait complètement. Elle restait visible, mais impossible à fermer ou à interagir avec.
Le programme semblait bloqué.
En analysant le comportement et en utilisant des impressions de debug, j’ai constaté que le blocage n’était pas lié à l’écriture du
fichier ni à la logique du convertisseur, mais bien à un problème de gestion des threads dans Swing.
Swing repose sur un fonctionnement particulier : toute l’interface graphique est gérée par un seul thread dédié,
appelé l’Event Dispatch Thread (EDT). Ce thread est responsable de tout ce qui concerne l’interface utilisateur :
la gestion des clics, le rafraîchissement de la fenêtre, la fermeture, le dessin et l’affichage en général.
Tant que ce thread tourne correctement, l’application reste réactive.
L’EDT ne démarre réellement qu’après l’appel à la méthode permettant d’afficher la fenêtre. À partir de ce moment,
toutes les opérations qui modifient l’interface devraient strictement être exécutées sur ce thread.
C’est une règle fondamentale pour éviter les blocages.
En examinant mon programme, je me suis rendu compte que le problème venait de la manière dont j’avais structuré mon point d’entrée.
Mon programme principal créait la fenêtre, le contrôleur, puis lançait immédiatement tout le processus de conversion,
qui incluait le chargement du fichier image, le calcul des fréquences, la construction des arbres de Huffman,
la génération des codes canoniques, et éventuellement l’écriture du fichier PIF.
Ce sont des opérations potentiellement longues et qui se déroulaient sur le thread principal,
avant même que l’EDT ne prenne le relais pour gérer l’interface.
Cela avait pour conséquences que Swing se retrouvait dans un état instable, puisque certaines opérations graphiques avaient été réalisées
hors du thread dédié.
C’est exactement ce qui provoquait le gel de l’interface : une fois le fichier enregistré, la fenêtre ne répondait plus car
l’EDT était bloqué ou interrompu, empêchant toute interaction, y compris la fermeture de la fenêtre.
Une fois le problème identifié, les solutions étaient claires. Il fallait s’assurer que toutes les opérations qui touchent
a l’interface graphique soient exécutées sur l’Event Dispatch Thread. Cela signifie que toute interaction, y compris l’ouverture
d’un sélecteur de fichiers, doit obligatoirement être déclenchée dans ce contexte. De plus, il fallait veiller à ne pas exécuter
de longues opérations synchrones avant le démarrage complet de l’EDT.
La solution consiste donc à déléguer l’appel du processus de conversion au thread graphique, en utilisant le mécanisme fourni par
Swing pour garantir que le code s’exécute sur l’EDT. Une autre possibilité serait d’exécuter les opérations lourdes dans un thread en
arrière-plan pour éviter de bloquer l’interface, mais dans tous les cas le respect strict de la séparation entre traitements et interface
est essentiel.
Grâce à cette analyse, j’ai mieux compris la manière dont Swing gère les threads et j’ai pu corriger la structure de mon programme
afin qu’il reste totalement réactif, même après l’export. Cette expérience m’a rappelé l’importance de maîtriser les principes fondamentaux
des bibliothèques graphiques et leurs contraintes en matière de multithreading.
Learning log – Problème de blocage de la fenêtre après la sauvegarde:
Après avoir implémenté la fonctionnalité d’export au format PIF depuis l’interface du convertisseur,
j’ai rencontré un problème important : une fois que je cliquais sur le bouton d’exportation,
la fenêtre se figeait complètement. Elle restait visible, mais impossible à fermer ou à interagir avec.
Le programme semblait bloqué.
En analysant le comportement et en utilisant des impressions de debug, j’ai constaté que le blocage n’était pas lié à l’écriture du
fichier ni à la logique du convertisseur, mais bien à un problème de gestion des threads dans Swing.
Swing repose sur un fonctionnement particulier : toute l’interface graphique est gérée par un seul thread dédié,
appelé l’Event Dispatch Thread (EDT). Ce thread est responsable de tout ce qui concerne l’interface utilisateur :
la gestion des clics, le rafraîchissement de la fenêtre, la fermeture, le dessin et l’affichage en général.
Tant que ce thread tourne correctement, l’application reste réactive.
L’EDT ne démarre réellement qu’après l’appel à la méthode permettant d’afficher la fenêtre. À partir de ce moment,
toutes les opérations qui modifient l’interface devraient strictement être exécutées sur ce thread.
C’est une règle fondamentale pour éviter les blocages.
En examinant mon programme, je me suis rendu compte que le problème venait de la manière dont j’avais structuré mon point d’entrée.
Mon programme principal créait la fenêtre, le contrôleur, puis lançait immédiatement tout le processus de conversion,
qui incluait le chargement du fichier image, le calcul des fréquences, la construction des arbres de Huffman,
la génération des codes canoniques, et éventuellement l’écriture du fichier PIF.
Ce sont des opérations potentiellement longues et qui se déroulaient sur le thread principal,
avant même que l’EDT ne prenne le relais pour gérer l’interface.
Cela avait pour conséquences que Swing se retrouvait dans un état instable, puisque certaines opérations graphiques avaient été réalisées
hors du thread dédié.
C’est exactement ce qui provoquait le gel de l’interface : une fois le fichier enregistré, la fenêtre ne répondait plus car
l’EDT était bloqué ou interrompu, empêchant toute interaction, y compris la fermeture de la fenêtre.
Une fois le problème identifié, les solutions étaient claires. Il fallait s’assurer que toutes les opérations qui touchent
a l’interface graphique soient exécutées sur l’Event Dispatch Thread. Cela signifie que toute interaction, y compris l’ouverture
d’un sélecteur de fichiers, doit obligatoirement être déclenchée dans ce contexte. De plus, il fallait veiller à ne pas exécuter
de longues opérations synchrones avant le démarrage complet de l’EDT.
La solution consiste donc à déléguer l’appel du processus de conversion au thread graphique, en utilisant le mécanisme fourni par
Swing pour garantir que le code s’exécute sur l’EDT. Une autre possibilité serait d’exécuter les opérations lourdes dans un thread en
arrière-plan pour éviter de bloquer l’interface, mais dans tous les cas le respect strict de la séparation entre traitements et interface
est essentiel.
Grâce à cette analyse, j’ai mieux compris la manière dont Swing gère les threads et j’ai pu corriger la structure de mon programme
afin qu’il reste totalement réactif, même après l’export. Cette expérience m’a rappelé l’importance de maîtriser les principes fondamentaux
des bibliothèques graphiques et leurs contraintes en matière de multithreading.
le proble aussi avec mon flush infini