Accélération Matérielle Java

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 l'accélération du rendu, passez cet arg (- Dsun.java2d. opengl=true) au lanceur Java au démarrage du programme, ou définissez-le avant d'utiliser des bibliothèques de rendu. System.setProperty("sun.java2d.opengl", "true"); C'est un paramètre optionnel.

2) Yes BufferedImage encapsule certains détails de la gestion de la mémoire volatile car, lorsque le BufferdImage est accéléré, une copie de celui-ci est stockée dans la V-Ram en tant que VolatileImage.

L'envers d'un BufferedImage est tant que vous ne jouez pas avec les pixels qu'il contient, il suffit de les copier comme un appel à graphics.drawImage(), puis le 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'un BufferedImage est que si vous faites de l'édition d'image, en changeant les pixels dans le BufferedImage, dans certains cas, il renoncera à essayer de l'accélérer, à ce moment-là si vous recherchez un rendu performant pour votre édition vous devez envisager de gérer votre propre VolatileImage. Je ne sais pas quelles opérations font renoncer le BufferedImage à essayer d'accélérer le rendu pour vous.

3) L'avantage d'utiliser le createCompatibleImage()/createCompatibleVolatileImage() est-ce que ImageIO.read() ne fait aucune conversion vers un modèle de données d'image pris en charge par défaut. Donc, 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 en données d'image compatibles Modèle.

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 image io en un BufferedImage qui a un Modèle de Données d'image compatible avec le périphérique d'écran par défaut afin que la conversion n'ait pas besoin d'avoir lieu quand elle est rendue. Les moments où cela est le plus avantageux est quand vous serez rendu l'image très fréquemment.

4) Vous n'avez pas besoin de faire un effort pour grouper votre rendu d'image car pour la plupart Java tentera de le faire pour vous. Il n'y a aucune raison pour laquelle vous ne pouvez pas essayer de le faire, mais en général, il est préférable de profiler vos applications et de confirmer qu'il existe un goulot d'étranglement au niveau du code de rendu d'image avant de tenter d'effectuer une optimisation des performances telle que celle-ci. Le principal inconvénient est qu'il soit implémenté légèrement différemment dans chaque JVM et que les améliorations pourraient être sans valeur.

5) À ma connaissance la conception que vous avez décrite est l'une des meilleures stratégies disponibles lorsque vous effectuez une double mise en mémoire tampon manuellement et le rendu actif d'une application. http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html Sur ce lien, vous trouverez une description du BufferStrategy. Dans la description, il montre un extrait de code qui est la façon recommandée de faire un rendu actif avec un objet BufferStrategy. 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éé le {[16] } sur une instance de un Canvas que j'ai mis sur un JFrame.