When working with BufferedImage using the setRGB and getRGB methods, I noticed two things:
the setRGB开发者_开发问答 and getRGB methods can be incredibly slow on some systems (as much as two orders of magnitude slower than modifiyng the int[] array).
there are no guarantee that a getRGB following a setRGB will give back the same pixel you passed
This last point is basically pretty clear from the JavaDoc of setRGB, which states:
...For images with an IndexColorModel, the index with the nearest color is chosen.
Seen I can work directly in a BufferedImage's int[] pixels, which I can access to by doing, for example:
int[] a = ((DataBufferInt) tmp.getRaster().getDataBuffer()).getData();
I was wondering: are there any known drawbacks/gotchas when directly manipulating pixels in the int[]
?
The whole point of getData() giving you access to the backing int array is precisely for this optimization, so the benefits most likely outweigh the drawbacks.
The drawbacks depend on how you're using the buffered image. If you're drawing it to the screen while you're editing it, you may encounter some artifacts on the screen (like pixels not colored in time), in which case you should consider double buffering (which does involve copying over the entire image for every refresh).
Not sure if this is relevant for your question, but you will run into problems when the BufferedImage was created using the method getSubimage(int x, int y, int w, int h)
.
Returns a subimage defined by a specified rectangular region. The returned BufferedImage shares the same data array as the original image.
The methods getTileGridXOffset()
and getTileGridYOffset()
return the offset then despite being described as
Returns the x offset of the tile grid relative to the origin, For example, the x coordinate of the location of tile (0, 0). This is always zero.
but because you can't (as far as I know) access the scanlineStride
field of the raster you won't be able to get the correct index for the array.
精彩评论