Forcer une actualisation complète de l'applet Java (AWT)

Question

J'ai une applet Java qui utilise AWT. Dans certaines (rares) circonstances, la plate-forme n'actualise pas correctement l'écran. Je peux déplacer ou réduire/agrandir la fenêtre et voir que mon applet s'est rafraîchi correctement. Je suis à la recherche de code qui me donnera le repeindre le plus complet de l'applet, en simulant le comportement d'une minimisation/maximisation.

J'ai essayé d'appeler différentes combinaisons de paint()/repaint()/invalidate()/update() sur les conteneurs parents et récursif sur divers enfants. Cependant, aucune combinaison (que j'ai trouvée) ne nettoie les bogues de framework que je rencontre. Je suis à la recherche de techniques pour actualiser complètement l'applet, même si elles peuvent provoquer un léger scintillement, car j'appellerai ce code uniquement sur la plate-forme problématique.

Dans mes tests, le passage à Swing n'a pas aidé à résoudre mon problème.

D'ailleurs, cela est une simplification de ma précédente (plus compliqué) après: Java Applet, AWT Refresh problem Mac OS X 10.4

Edit: enquête dans le filetage n'a pas résolu ce problème. Marquer la meilleure réponse comme la bonne.

Answer 1

Cela arrive tout le temps si vous ne programmez pas avec attention dans AWT/Swing. Tout d'abord, vous devez faire tout le travail sur le thread d'événement. Cela signifie que vous ne pouvez rien faire dans votre déclaration principale (ou tout ce qu'elle appelle directement). Je sais que chaque application Java GUI jamais inventé viole cette règle, mais c'est la règle. Pour la plupart, ils disaient que vous pouviez utiliser un thread non-awt jusqu'à ce que la fenêtre soit "Realized" (pack/setVisible), mais Sun a compris que cela ne fonctionnait pas toujours. Deuxièmement, lorsque vous obtenez un événement sur le thread AWT, veillez à le renvoyer rapidement. Ne jamais dormir ou exécuter une longue opération.

Troisièmement, (ce qui est une extension de « First », si vous obtenez un rappel qui n'est pas déjà sur le thread de travail AWT, assurez-vous de le mettre sur le fil AWT avant de faire quoi que ce soit avec l'interface graphique.

Généralement, tout événement généré par un composant AWT se trouve sur le bon thread Les événements générés par des temporisateurs, des threads créés manuellement ou par celui transmis à main() ne le sont pas

Answer 2

La méthode à utiliser pour ce genre de problème est de repeindre, comme vous l'avez mentionné. Il est possible que vous voyiez un problème avec la machine virtuelle Java que vous utilisez. Je vous recommande d'utiliser différentes versions de la JVM Sun et même de la VM MS pour IE pour voir s'il s'agit d'un problème lié à la machine virtuelle - il se peut que cela ne soit pas lié à votre code. Je n'ai pas encore essayé cela, mais un moyen créatif (c'est-à-dire un hack méchant) autour de ceci pourrait être d'exécuter javascript à partir de l'applet pour appeler une méthode DOM pour faire un redimensionnement de la fenêtre ou appeler focus sur le corps dans une tentative de provoquer un re-dessin externe de la toile.

Answer 3

mon Applet AWT redessiner les problèmes en passant à Swing.Swing semble être plus fiable sur le rafraîchissement

Plus tôt, j'ai eu beaucoup de rep manuel aints() dans mon code applet, mais avec Swing, ils ont été supprimés et l'applet est maintenant plus rapide, en particulier sous Terminal Server/LTSP.

Je mis des choses critiques dans ce:

public class VeryFastPanel extends JPanel { 



    /** 
     * 
     */ 
     private static final long serialVersionUID = 1L; 

     public void update(Graphics g) { 

     paint(g); 
    } 

} 

Answer 4

Je ne sais pas si cela est lié à ce que vous avez vu, mais si vous obtenez contre les performances de la file d'attente d'événements AWT Java 2d + 3d monde (les gens de pipeline de graphiques) pointera dans une stratégie filetée et alors vous obtiendrez dans le problème de disposer. Cette discussion a porté sur les conceptions utilisant la file d'attente d'événements AWT pour les graphiques, comme dans l'utilisation de "repaint".

Dans l'approche filetée, il y a un problème d'arrêt. Notes dans java/awt/SequencedEvent pour "disposer" pointent vers "AWT Threading Issues" et "Autoshutdown". Je pense que cette information sert au moins à focaliser le problème.

Answer 5

J'ai trouvé un problème qui semble être le même que celui que vous rencontrez. Après quelques tests, j'ai découvert que cela pouvait être lié aux adaptateurs Aero et Intel Graphics. Dans mon cas, l'application a cessé de repeindre seulement lorsqu'elle est utilisée dans des ordinateurs portables sans adaptateurs secteur, alimentés par des piles. Si vous désactivez certaines fonctions d'économie d'énergie dans la configuration du pilote Intel (notamment Intel 2D Display Technology dans les anciennes versions de pilotes), Java sera repeint normalement.

Dans mon cas, j'ai trouvé aussi des moyens de désactiver cette option via le registre. Ce n'est pas documenté, mais ça fonctionne.