2008/8/22 Douglas Adler <dad...@tripleplayint.com>:
2008/8/21 Wayne Meissner [wmei...@gmail.com]:
if (ptr != null) {
ptr.read(0, vidBuffer, 0, vidWidth * vidHeight);
renderImage.setRGB(0, 0, vidWidth, vidHeight, vidBuffer, 0,
vidWidth);
g2d.drawImage(renderImage, 0, 0, width, height, null);
}
You can avoid one copy above with:
int[] pixels = ((DataBufferInt)
renderImage.getRaster().getDataBuffer()).getData();
ptr.read(0, pixels, 0, vidWidth * vidHeight);
That only works on BufferedImage.TYPE_INT_RGB, but thats what one
would normally allocate as a backing buffer anyway.
You can also get some speed on some platforms when scaling the final
image by painting that heap buffer into a volatile buffer, then
scaling the volatile buffer into the swing buffer (ie. the Graphics
passed into paintComponent).
http://trac-hg.assembla.com/gstreamer-java/browser/src/org/gstreamer/swing/VideoComponent.java
contains some comments on wringing out video rendering performance on
swing.
I am still trying to figure out how to use the directly allocated buffer as
the backing store for a raster, but I can't see the path yet. This would
remove the need for the at least one of the copies.
As far as I know, there is no way to use a direct ByteBuffer as the
source for a Raster - its just not supported by swing.
If you can get the number of superfluous copies down to one (decode to
native buffer, copy native buffer to BufferedImage), declare victory
and move on. There have been many discussions on teh interwebs about
it, and it just isn't possible to do zero-copy decoding ->
BufferedImage. At least not yet.
12 messages in net.java.dev.jna.usersRe: [jna-users] Getting pointers from...
