 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
12 messages in net.java.dev.jna.usersRe: [jna-users] Getting pointers from...| From | Sent On | Attachments |
|---|---|---|
| Douglas Adler | Aug 20, 2008 12:03 pm | |
| Timothy Wall | Aug 20, 2008 12:55 pm | |
| Wayne Meissner | Aug 20, 2008 6:37 pm | |
| Douglas Adler | Aug 21, 2008 11:56 am | |
| Timothy Wall | Aug 21, 2008 12:18 pm | |
| Wayne Meissner | Aug 21, 2008 3:47 pm | |
| Wayne Meissner | Aug 21, 2008 3:55 pm | |
| Timothy Wall | Aug 22, 2008 7:41 am | |
| Wayne Meissner | Aug 22, 2008 3:57 pm | |
| Timothy Wall | Aug 22, 2008 4:04 pm | |
| Wayne Meissner | Aug 22, 2008 4:39 pm | |
| Scott Palmer | Aug 22, 2008 6:47 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [jna-users] Getting pointers from java | Actions... |
|---|---|---|
| From: | Timothy Wall (twal...@dev.java.net) | |
| Date: | Aug 21, 2008 12:18:26 pm | |
| List: | net.java.dev.jna.users | |
Have you tried simply passing "int[]" to the native method instead of the direct buffer?
Unless the array is stored discontiguously, you can avoid the extra data copy altogether.
On Aug 21, 2008, at 2:57 PM, Douglas Adler wrote:
2008/8/21 Wayne Meissner [wmei...@gmail.com]:
2008/8/21 Timothy Wall <twal...@dev.java.net>:
In addition, there's a Pointer.read() method that reads into an existing int[] to avoid allocating a new one every time.
That would be the best way if you're going to be accessing the pixels from java (Pointer and ByteBuffer ops will be slower than array element accesses).
Its not the copy that is killing performance, it's the garbage collector.
Thanks.
So now I do the following to create the memory region.
ByteBuffer bytes = ByteBuffer.allocateDirect(vidWidth * vidHeight * vidDepth); IntBuffer data = bytes.asIntBuffer(); Pointer ptr = Native.getDirectBufferPointer(data); BufferedImage renderImage = (BufferedImage) createImage(width, height); int [] vidBuffer = new int[vidWidth * vidHeight];
The ptr gets passed to the native library and on return I now do this in the paintComponent function:
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); }
I think the ptr.read() change is giving me the biggest boost. I can now render SD video onto a 1280x720 frame (cpu @ ~65% on a 3GHz Pentium 4). HD video is still taking too much cpu in the decode to keep the frame rate up.
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.