Java Accélération Matérielle

1) La mesure de l'accélération matérielle n'est jamais activé par défaut, et à ma connaissance il n'a pas encore changé. Pour activer le rendu de l'accélération passez cet arg (- Dsun.java2d.opengl=true) au lanceur Java au démarrage du programme, ou le configurer avant d'utiliser toute bibliothèque de rendu. System.setProperty("sun.java2d.opengl", "true"); C'est un paramètre facultatif.

2) Oui BufferedImage encapsule certains détails de la gestion de la mémoire Volatile parce que, lorsque le BufferdImage est accéléré une copie est conservée en V-Ram comme un VolatileImage.

La tête à la une BufferedImage est aussi longtemps que vous ne jouez pas avec les pixels qu'il contient, simplement les copier comme un appel à graphics.drawImage(), puis BufferedImage sera accéléré après un certain nombre non spécifié de copies et il gérera le VolatileImage pour vous.

L'inconvénient d'une BufferedImage si vous faites du retouche d'image, changez les pixels dans le BufferedImage, dans certains cas, il va essayer d'accélérer, à ce stade, si vous êtes à la recherche pour Rendu performant pour votre édition, vous devez envisager de gérer votre propre VolatileImage. Je ne sais pas les opérations qui font l' BufferedImage renoncez à essayer d'accélérer le rendu pour vous.

3) L'avantage de l'utilisation de l' createCompatibleImage()/createCompatibleVolatileImage() c'est que ImageIO.read() ne fait aucune conversion vers un modèle de données D'Image pris en charge par défaut. Ainsi, si vous importez un PNG, il le représentera dans le format construit par le lecteur PNG. Cela signifie que chaque fois qu'il est rendu par un GraphicsDevice il doit d'abord être converti à un modèle de données D'Image compatible.

BufferedImage image = ImageIO.read ( url );
BufferedImage convertedImage = null;
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment ();
GraphicsDevice gd = ge.getDefaultScreenDevice ();
GraphicsConfiguration gc = gd.getDefaultConfiguration ();
convertedImage = gc.createCompatibleImage (image.getWidth (), 
                                           image.getHeight (), 
                                           image.getTransparency () );
Graphics2D g2d = convertedImage.createGraphics ();
g2d.drawImage ( image, 0, 0, image.getWidth (), image.getHeight (), null );
g2d.dispose()

le processus ci-dessus convertira une image lue avec l'api io d'image en un BufferedImage qui a un modèle de données D'Image compatible avec le dispositif d'écran par défaut de sorte que la conversion n'a pas besoin d'avoir lieu quand jamais il est rendu. Les moments où cela est le plus avantageux est quand vous rendrez l'image très fréquemment.

4) Vous n'avez pas besoin de faire un effort de fournée votre Rendu d'image parce que pour le la plupart du temps, Java tentera de le faire pour vous. Il n'y a pas de raison pour que vous n'essayiez pas de le faire, mais en général, il est préférable de profiler vos applications et de confirmer qu'il y a un goulot d'étranglement dans le code de rendu d'image avant de tenter d'effectuer une optimisation des performances comme celle-ci. Le principal inconvénient est qu'il peut être mis en œuvre un peu différemment dans chaque JVM et que les améliorations peuvent alors être sans valeur.

5) À ma connaissance, le design que vous avez outlined est l'une des meilleures stratégies là-bas quand faire double tampon manuellement et activement rendre une application. http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html Sur ce lien, vous trouverez une description de l' BufferStrategy. Dans la description il y a un extrait de code qui est la façon recommandée de faire un rendu actif avec un BufferStrategy objet. J'utilise cette technique particulière pour mon code de rendu actif. La seule différence majeure est que dans mon code. comme vous, j'ai créé l' BufferStrategy sur une instance d'un Canvas que j'ai mis sur un JFrame.