java - móviles - manual de programacion android pdf

Aceleración de hardware de Java

Question

He estado estudiando las características de aceleración de hardware de Java, y todavía estoy un poco confundido ya que ninguno de los sitios que encontré en línea respondió de manera directa y clara algunas de las preguntas que tengo. Estas son las preguntas que tengo para la aceleración de hardware en Java:

1) En Eclipse versión 3.6.0, con la actualización más reciente de Java para Mac OS X (creo que es 1.6u10), ¿la aceleración de hardware está habilitada por defecto? Leí en algún lado que

someCanvas.getGraphicsConfiguration().getBufferCapabilities().isPageFlipping()

se supone que da una indicación de si la aceleración de hardware está habilitada o no, y mi programa informa de manera verdadera cuando se ejecuta en mi instancia principal de Canvas para dibujar. Si mi aceleración de hardware no está habilitada ahora, o de manera predeterminada, ¿qué tendría que hacer para habilitarla?

2) He visto un par de artículos aquí y allá sobre la diferencia entre una Imagen Buffered y VolatileImage, principalmente diciendo que VolatileImage es la imagen acelerada por hardware y se almacena en VRAM para operaciones de copia rápida. Sin embargo, también encontré algunas instancias donde se dice que BufferedImage también está acelerado por hardware. ¿El hardware de BufferedImage también se acelera en mi entorno? ¿Cuál sería la ventaja de usar una imagen volátil si ambos tipos están acelerados por hardware? Mi principal supuesto para la ventaja de tener una imagen volátil en el caso de que ambos tengan aceleración es que VolatileImage es capaz de detectar cuándo se ha abandonado su VRAM. Pero si BufferedImage también es compatible con la aceleración ahora, ¿no tendría también el mismo tipo de detección incorporada, simplemente oculto para el usuario, en caso de que la memoria se descargue?

3) ¿Hay alguna ventaja al usar

someGraphicsConfiguration.getCompatibleImage/getCompatibleVolatileImage()

Opuesto a

ImageIO.read()

En un tutorial que he estado leyendo sobre algunos conceptos generales sobre cómo configurar la ventana de renderizado correctamente ( tutorial ), utiliza el método getCompatibleImage, que creo que devuelve una imagen Buffered, para obtener imágenes "aceleradas por hardware" para un dibujo rápido, lo que se relaciona 2 acerca de si es hardware acelerado.

4) Esto es menos aceleración de hardware, pero es algo que me ha llamado la atención: ¿necesito ordenar qué gráficos se dibujan? Sé que al usar OpenGL a través de C / C ++ es mejor asegurarse de que se dibuje el mismo gráfico en todas las ubicaciones que necesita dibujar de una vez para reducir el número de veces que la textura actual necesita ser cambiada. Por lo que he leído, parece que Java se ocupará de esto para mí y se asegurará de que las cosas se dibujen de la manera más óptima, pero una vez más, nada ha dicho algo como esto claramente.

5) ¿Qué clases de AWT / Swing admiten la aceleración de hardware y cuáles deberían usarse? Actualmente estoy usando una clase que amplía JFrame para crear una ventana y agregarle un lienzo desde el cual creo una estrategia BufferStrategy. ¿Es esta una buena práctica, o hay algún otro tipo de forma en que debería implementar esto?

Muchas gracias por su tiempo, y espero haberles proporcionado preguntas claras y suficiente información para que respondan mis varias preguntas.

Answer 1

1) Hasta ahora, la aceleración de hardware nunca está habilitada por defecto, y que yo sepa, aún no ha cambiado. Para activar la aceleración de representación, pase esta arg (-Dsun.java2d.opengl = true) al iniciador de Java al iniciar el programa, o configúrelo antes de usar cualquier biblioteca de renderizado. System.setProperty("sun.java2d.opengl", "true"); Es un parámetro opcional.

2) Sí BufferedImage encapsula algunos de los detalles de la gestión de la memoria volátil porque, cuando se acelera la imagen de BufferdImage una copia de esta se almacena en V-Ram como una imagen VolatileImage .

El lado positivo de una BufferedImage es siempre que no esté jugando con los píxeles que contiene, simplemente copiándolos como una llamada a graphics.drawImage() , luego BufferedImage se acelerará después de un cierto número de copias no especificadas y se administrará la imagen VolatileImage para ti.

La desventaja de una Imagen BufferedImage es que si está editando imágenes, cambiando los píxeles en la Imagen BufferedImage , en algunos casos dejará de intentar acelerarlo, en ese punto si está buscando renderizado para su edición, debe considerar administrar tu propia imagen VolatileImage No sé qué operaciones hacen que BufferedImage rinda al tratar de acelerar el procesamiento por usted.

3) La ventaja de usar createCompatibleImage()/createCompatibleVolatileImage() es que ImageIO.read() no realiza ninguna conversión a un modelo de datos de imagen admitido por defecto. Por lo tanto, si importa un archivo PNG, lo representará en el formato creado por el lector PNG. Esto significa que cada vez que sea renderizado por un GraphicsDevice , primero debe convertirse a un Modelo de Datos de Imagen 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()

El proceso anterior convertirá una imagen leída con la imagen io api en una Imagen Buffered que tiene un Modelo de Datos de Imagen compatible con el dispositivo de pantalla predeterminado para que la conversión no tenga lugar cada vez que se represente. Los momentos en que esto es más ventajoso es cuando va a renderizar la imagen con mucha frecuencia.

4) No necesita hacer un esfuerzo para agrupar el procesamiento de su imagen porque, en su mayor parte, Java intentará hacer esto por usted. No hay ninguna razón por la cual no pueda intentar hacer esto, pero en general es mejor perfilar sus aplicaciones y confirmar que hay un cuello de botella en el código de representación de la imagen antes de intentar llevar a cabo una optimización del rendimiento como esta. La principal desventaja es que puede ser implementado de forma ligeramente diferente en cada JVM y luego las mejoras pueden ser inútiles.

5) A mi leal saber y entender, el diseño que ha descrito es una de las mejores estrategias que existen al realizar el Doble Buffering de forma manual y renderizando activamente una aplicación. http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html En este enlace encontrará una descripción de BufferStrategy . En la descripción, muestra un fragmento de código que es la forma recomendada de hacer una representación activa con un objeto BufferStrategy . Utilizo esta técnica particular para mi código de renderizado activo. La única diferencia importante es eso en mi código. como tú, he creado BufferStrategy en una instancia de un Canvas que coloqué en un JFrame .

Answer 2

A juzgar por la documentación anterior , puede indicar en las JVM de Sun si la aceleración de hardware está sun.java2d.opengl o no controlando la propiedad sun.java2d.opengl .

Lamentablemente, no sé si esto se aplica a Apple JVM.

Puede verificar si una imagen individual es acelerada por hardware usando getCapabilities(GraphicsConfiguration).isAccelerated()

Habiendo dicho todo esto, toda la documentación que he visto (incluida esta ) implica que BufferedImage no está acelerado por hardware. Swing también ha sido cambiado para usar VolatileImage s para su doble buffer por esta misma razón.