>You can > then dig out the > appropriate Raster, or DataBuffer, or raw Java array > from that image for > more direct access if you need it. For example: > > BufferedImage img = new > w BufferedImage(w,h,TYPE_INT_RGB); > WritableRaster wr = img.getRaster(); > // These maintain manageability on all releases that > // support managed images, listed in rough order of > // probably fastest to probably slowest (though it > t can > // still depend on format - YMMV): > wr.setDataElements(...); > wr.setPixels(...); > wr.setSamples(...);
*************** > // or, this defeats manageable on JDK 6 and prior: > DataBufferInt dbi = wr.getDataBuffer(); > dbi.setElem(...); > // or, this defeats manageable on JDK 7 and prior: > // (and probably future VMs as well) > int buf[] = dbi.getData(); > buf[...] = ...; > *************** But this way is the fastest way to build a whole frame pixel by pixel as I have to do in my applet. I use the source pixels from the input image as data. I construct a whole new image frame [pixel set] from the input image/data. I don't care if the input image is manageable or if it's even an image. You've heard my request to read an image file directly into a byte or integer array. So I use the input image as data to construct my new output image/frame/pixel array by subsampling the input data. I interpolate around a 4x4 neighborhood to construct a wholly unique pixel then shove it into the output pixel array. Having a managed output image is important. That's why I used MemoryImageSource in the past. But that has become a neglected API and is now slower than using an un-managed BufferedImage. So I now use an unmanaged BufferedImage. I use the BI unmanaged because using the WriteableRaster methods to set individual pixels are more costly than a simple assignment to the DataBuffer. And using a temporary array or compatible WriteableRaster necessitates either doubling the size of memory used to create the output array (important for an applet using fullscreen mode) and/or requires a copy of the entire array to the WriteableRaster . And all that becomes slower than making the BufferedImage unmanaged and using simple assigments to the DataBuffer like below. > // or, this defeats manageable on JDK 7 and prior: > // (and probably future VMs as well) > int buf[] = dbi.getData(); > buf[...] = ...; > The above is the fastest way to construct a whole new image frame and most efficient in use of memory. Too bad it makes the BufferedImage unmanaged. There is a measurable speed up with a managed image and that makes for a better user experience especially when in fullscreen mode. But using the methods that guarantee a managed image is actually slower than using an unmanaged image when building large images pixel by pixel. My suggestion is to also allow direct assignment to the DataBuffer while still maintaining image manageability and give the programmer both the responsibility and the tools to make sure image data is consistent. I expect no response to this message other than the usual acrimony. [Message sent by forum member 'demonduck' (demonduck)] http://forums.java.net/jive/thread.jspa?messageID=351113 =========================================================================== To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
