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

Question

J'ai une applet Java qui utilise AWT. Dans certaines circonstances (rares), la plate-forme n'actualise pas l'écran correctement. Je peux déplacer ou minimiser / agrandir la fenêtre et voir que mon applet a été actualisé correctement. Je suis à la recherche d'un code qui me permettra de repeindre l'écran d'applet le plus complet possible, en simulant le comportement d'une réduction / une maximisation.

J'ai essayé d'appeler diverses combinaisons de paint () / repaint () / invalidate () / update () sur les conteneurs parents et de faire des rappels sur différents enfants. Cependant, aucune combinaison (que j'ai trouvée) ne nettoie les bugs de framework que je rencontre. Je recherche des techniques pour actualiser complètement l'applet, même si elles peuvent provoquer un léger scintillement, car je n'invoquerai ce code que sur la plate-forme problématique.

Lors de mes tests, le passage à Swing n’a pas aidé à résoudre mon problème.

À propos, ceci est une simplification de mon précédent message (plus compliqué): Applet Java, problème d'actualisation AWT Mac OS X 10.4

Modifier: Une enquête sur les threads n'a pas résolu ce problème. Marquant la meilleure réponse comme bonne.

Answer 1

Cela se produit tout le temps si vous ne programmez pas soigneusement dans AWT / Swing.

Tout d’abord, vous devriez effectuer TOUT travail sur le fil 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 d'interface graphique Java jamais inventée enfreint cette règle, mais c'est la règle.

Dans la plupart des cas, ils disaient que vous pouviez utiliser un thread non-awt jusqu'à ce que la fenêtre soit "Réalisée". (pack / setVisible), mais Sun a découvert que cela ne fonctionnait pas toujours.

Deuxièmement, lorsque vous recevez un événement sur le fil AWT, veillez à le renvoyer rapidement. Ne jamais dormir ou exécuter une longue opération.

Troisièmement (et il s’agit d’une extension de "Premier", si vous recevez un rappel qui n’EST PAS déjà sur le thread de travail AWT, veillez à le placer sur le thread AWT avant de faire quoi que ce soit avec l’interface graphique.

En règle générale, tout événement généré par un composant AWT sera sur le bon thread. Les événements générés par des minuteurs, des threads créés manuellement ou ceux remis à main () ne le sont pas.

Answer 2

La méthode à utiliser pour résoudre ce type de problème est de repeindre, comme vous l'avez mentionné. Il est possible que vous constatiez un problème avec la machine virtuelle que vous utilisez. Nous vous recommandons d’utiliser différentes versions de la machine virtuelle Java Sun et même de la machine virtuelle MS pour IE afin de déterminer s’il s’agit d’un problème lié à une machine virtuelle - il se peut qu’il n’ait aucun rapport avec votre code.

Je n’ai pas réellement essayé cela auparavant, mais une façon créative (c’est-à-dire un bidouillage méchant) pourrait être d’exécuter du javascript à partir de l’applet pour appeler une méthode DOM afin de redimensionner la fenêtre ou d’appeler le focus sur le corps dans le but de provoquer un re-dessin externe de la toile.

Answer 3

Vous ne savez pas si cela est lié à ce que vous avez vu, mais si vous vous opposez aux performances de la file d'attente d'événements AWT, le monde java 2d + 3d (les utilisateurs de pipeline graphique) pointera dans une stratégie threadée, puis vous ' Je vais entrer 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, par exemple, en utilisant "repeindre".

Dans l'approche par thread, il y a un problème d'arrêt.

Notes dans java / awt / SequencedEvent pour "disposer". pointez-nous sur " AWT Threading Issues " et "Autoshutdown".

Je pense que cette information sert au moins à concentrer le problème.

Answer 4

J'ai pu résoudre 99% des problèmes de mise à jour de mon applet AWT en basculant sur Swing. Swing semble être plus fiable sur le rafraîchissement.

Auparavant, le code de mon applet contenait beaucoup de repeints (), mais avec Swing, ceux-ci ont été supprimés et l'applet est maintenant plus rapide, en particulier sous Terminal Server / LTSP.

J'ai placé des éléments critiques à l'intérieur de ceci:

public class VeryFastPanel extends JPanel {



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

        public void update(Graphics g) {

      paint(g);
    }

}

Answer 5

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

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