Cuando se trabaja con BufferedImage utilizando el setRGB y GetRGB métodos, me di cuenta de dos cosas:Trabajando en int de un BufferedImage [] píxeles gama
la setRGB y getRGB métodos puede ser increíblemente lento en algunos sistemas (tanto como dos órdenes de magnitud más lento que modifiyng la matriz int []).
No hay garantía de que un getRGB después de una setRGB devolverá el mismo píxel que ha pasado
Este último punto es básicamente bastante claro desde el JavaDoc de setRGB, que estados:
... Para imágenes con IndexColorModel, el índice con el color más cercano es elegido.
Seen puedo trabajar directamente en píxeles de un BufferedImage int [], que puedo tener acceso a por hacer, por ejemplo:
int[] a = ((DataBufferInt) tmp.getRaster().getDataBuffer()).getData();
Me preguntaba: ¿Hay inconvenientes conocidos/trampas cuando directamente manipulando píxeles en el int[]?
+1 pero ¿podría dar más información acerca de cómo debe/debería hacerse el doble almacenamiento en búfer? – SyntaxT3rr0r
Cómo funciona el doble almacenamiento en búfer depende de varios factores, como lo que está mostrando, qué tan grande es, qué es el motor de gráficos, qué tan rápido una velocidad de actualización desea, si puede aprovechar lo que proporcionan sus gráficos tarjeta, etc. Pero una forma básica de hacerlo sería tener un búfer que modifique, y uno que muestre, copiando sobre el búfer modificado cuando haya terminado de hacer modificaciones. Una buena forma de hacerlo es copiar los datos en el búfer de modificación en un búfer de temperatura primero, de modo que la asignación del búfer de visualización al búfer de temperatura sea una operación rápida. –
Hay un problema de lectores/escritores allí donde debe asegurarse de que no está tratando de mostrar un búfer que se está copiando. Si está haciendo todo esto en un solo hilo, puede salirse con la suya con algo como 'if (doneCopying) {displayBuf = tmpBuf; } draw (displayBuf); ' –