Traduction officieuse du tutorial de Michael Martak. Dont je n'ai pas trouvé l'e-mail: si ca dérange quelqu'un, je veux bien enlever cette traduction.
La version originale est sur java.sun.com (et ici un zip contenant la traduction pour la regarder offline )

BufferStrategy et BufferCapabilities

BufferStrategy

Dans l'édition standard de Java 2, vous n'avez pas à vous inquiéter des pointeurs ou de la mémoire video pour avoir tous les avantages du double-buffering ou du page-flipping. La nouvelle classe ava.awt.image.BufferStrategy a été ajoutée pour traiter confortablement le dessin des surfaces et des composants d'une façon commune, sans se soucier du nombre de buffers ou de la technique utilisés pour les afficher.

Une buffer strategy procure deux méthodes à tout faire pour le dessin: getDrawGraphics et show. Quand vous voulez commencer à dessiner, prenez un draw graphics et utilisez-le. Quand vous avez fini de dessiner et que vous voulez afficher vos renseignements à l'écran, appelez show. Ces deux méthodes sont là pour prendre place dans une boucle de rendu:

BufferStrategy myStrategy;

while (!done) {
    Graphics g = myStrategy.getDrawGraphics();
    render(g);
    g.dispose();
    myStrategy.show();
}

Les buffer strategies existent aussi pour vous aider à manipuler les problèmes concernant les VolatileImage. En mode plein écran, ceux-ci sont particulièrement important parce que le system de fenêtrage peut quelquefois reprendre la mémoire video qu'il vous avait donné. Un exemple important: quand on appuie sur ALT+TAB, d'un coup, le programme en plein écran tourne en arrière plan et la mémoire video est perdue. Vous pouvez utiliser la méthode contentsLost pour la retrouver. De la même manière, when the windowing system returns your memory to you, you can find out using the contentsRestored method.

BufferCapabilities

Comme mentionné précédemment, les OS et même les cartes graphiques sur un même OS on des techniques différentes à votre disposition. Ces capacités (capabilities) vous sont exposées de sorte que vous puissiez choisir la meilleure pour votre application.

La classe java.awt.BufferCapabilities regroupe ces capacités. Chaque buffer strategy est controllée par ses capacités de buffer, donc choisir la bonne pour votre application est crucial. Pour trouver les capacités disponibles, appelez la méthode etBufferCapabilities depuis les objets GraphicsConfiguration objects disponibles dans votre graphics device.

Les capacités disponibles dans Java 2 Standard Edition version 1.4 sont:

isPageFlipping

Cette capacité retourne si le page-flipping matériel est disponible sur cette configuration graphique.

isFullScreenRequired

Cette capacité retourne si le mode plein écran est requis avant d'utiliser le page-flipping matériel.

isMultiBufferAvailable

Cette capacité retourne si le multiple buffering matériel (deux back buffers ou plus ainsi que la surface primaire) est disponible.

getFlipContents

Cette capacité retourne une indication sur la technique utilisée par le matériel pour le page-flipping. C'est important parce que les contenus du back buffer après un show sont différents selon la technique utilisée. La valeur retournée peut être null ( si isPageFlipping retourne false) ou une des valeurs suivantes. Tout valeur peut être spécifiée à une buffer strategy tant que la méthode isPageFlipping retourne true, bien que les performances varieront en fonction des capacités disponibles.

FlipContents.COPIED

Cette valeur signifie que les contenus des back buffers sont copiés vers la surface primaire. Un "flip" a lieu probablement en tant que blt materiel, ce qui signifie que le double-buffering matériel est probablement fait en utilisant un blitting au lieu d'un vrai page-flipping. Ceci devrait (en théorie) être plus rapide, ou au moins aussi rapide, qu'un blitting depuis une VolatileImage vers la surface primaire, bien que la consommation (rq: en temps ?) puisse varier. Les contenus du back buffer sont les même que la surface primaire après un flip.

FlipContents.BACKGROUND

Cette valeur signifie que les contenus des back buffers ont été remplacés par la couleur de l'arrière plan (background). Soit un vrai page-flipping, soit un blt a eu lieu.

FlipContents.PRIOR

Cette valeur signifie que les contenus des back buffers sont maintenant les contenus de l'ancienne surface primaire, et vice versa. Généralement, cette valeur indique qu'il y a eu un vrai page-flipping, bien que ce ne soit pas garanti, une fois encore, le temps pris par cette opération peut varier.

This value means that the contents of the back buffer are now the contents of the old primary surface, and vice versa. Generally this value indicates that true page-flipping occurs, though this is not guaranteed and, once again, your mileage on this operation may vary.

FlipContents.UNKNOWN

Cette valeur signifie que les contenus des back buffers sont indéfinis après un flip. Vous devez faire des expériences pour savoir quelle technique marche le mieux pour vous (ou vous pouvez n'en avoir que faire), et vous devrez fixer les contenus des back buffers vous-même lors de chaque affichage.

Pour creer une buffer strategy pour un composant, appelez la méthode createBufferStrategy en fournissant le bombre de buffers désirés (ce nombre inclut la surface primaire). Si aucune technique particulière de buffering n'est désirée, fournissez un objet BufferCapabilities approprié. Il faut noter que lorsque vous utilisez cette version de la méthode, vous devez rattraper une AWTException dans l'évênement pour indiqué que votre choix n'est pas disponible (traduction de: you must catch an AWTException in the event that your choice is not available ). Notez aussi que ces méthodes sont seulement disponibles avec Canvas et Window.

Une fois qu'une buffer strategy particulière a été créée pour un composant, vous pouvez la manipuler en utilisant la méthode getBufferStrategy. Notez que cette méthode n'est aussi diponibles que pour les canvas et les window.

Astuces de programmation

Quelques astuces concernant les buffer capabilities et les buffer strategies:

• Obtenir, utiliser et disposer d'un objet graphics est plus robuste dans une clause try...finally:

  BufferStrategy myStrategy;
  
  while (!done) {
      Graphics g;
      try {
          g = myStrategy.getDrawGraphics();
          render(g);
      } finally {
          g.dispose();
      }
      myStrategy.show();
  }

• Examinez les capacités disponibles avant d'utiliser une buffer strategy.

• Pour de meilleurs résultats, créez votre buffer strategy sur une fenêtre en plein écran. Assurez vous que vous vérifiez les capacités isFullScreenRequired et isPageFlipping avant d'utiliser le page-flipping.

• Ne faites aucune supposition sur les performances. Ajustez votre code autant que nécessaire, mais rappelez vous que les different OS et cartes graphiques n'ont pas les même capacités.Profile your application!

• Vous voudrez peut-être sous-classer (subclass)votre composant pour remplacer la methode createBufferStrategy. Utilisez un algorithme pour choisir une strategy qui est la mieux adaptée à votre application. Les classes internes FlipBufferStrategy et BltBufferStrategy sont protected et peuvent être sous classées.

• N'oubliez pas que vous pouvez perdre vos surfaces d'affichage ! Vérifiez contentsLost et contentsRestored avant d'afficher. Tous les buffers qui ont été perdus doivent être redessiner quand ils ont été restaurés.

• Si vous utilisez une buffer strategy pour un double-buffering dans une application Swing, vous voulez probablement désactiver le double-buffering de vos composants Swing, puisqu'ils seront déjà double-buffered. La mémoire video est quelque chose de précieux et ne devrait être utilisée que lorsque c'est absolument nécessaire.

• Utiliser plus d'un back buffer finit par être du gaspillage. Le multi-buffering est seulement utile quand les temps d'affichage excèdent le temps passé lors d'un show. Profile your application!