Hi All, The task im trying to accomplish is displaying live video images from a video camera in a java application.
1. The hardware - The application should run on a Sun Blade 100 machine with Solaris 8 / CDE Desktop - The video is captured using a Snapper24 PCI frame grabber card that can capture 768x576 24bit color images at a frame rate of ~24fps and deliver the data to an arbitrary address in memory - The display frame buffer on my machine is Sun m64 graphic card 2. The problem: What im trying to achieve is smooth live video display with minimum cpu usage. All the solutions that i tried so far involves copying data from the framegrabber to machine RAM and from there to the framebuffer(m64) (sometimes the image data is copied even more than once). The main problem is that the copy of such large data using memcpy, consumes a lot of cpu and takes a lot of time, ~12ms per frame. My common sense says that there is no real need in copying the image to ram. if i could only find a way to deliver it directly to the frame buffer device (m64) through the pci bus, directly to the area of my java window or to an offscreen buffer residing in the framebuffer (that will be afterwards copied by the framebuffer to the vram/display) Why do i think that its possible? Because both the framegrabber and the framebuffer devices are connected on the same pci bus to the blade 3. The tests ive made: 3a. Ive made a java benchmarking application that simulates live video. The application creates 4 BufferedImage's using createCompatibleImage each of them representing a "frame" of video. Using a Swing timer, the images are displayed to the screen sequencially. The display operation is done by copying each frame into a "backbuffer" image (the same type as the four images) and displaying this image on the screen graphics (without swings double buffering). to make things even more interesting im also drawing a random rectangle on the backbuffer before its drawn to the screen. The perfromance i get are very nice, ~22 fps, the cpu is still alive ~60% and the gui is responsive 3b. Ive managed to capture images with my frame grabber with a frame rate of ~24 fps where each frame is put in a pre-allocated byte array (in native code). The cpu consumption was ~0, which makes sense because the copy is done by the framegrabber's cpu Now what i'd like to do is to find a way to update the "backbuffer" image mentioned in section 3a with the data from the framegrabber mentioned in section 3b, before drawing the backbuffer to screen (in java). I tried all sort of java/native techniques for this task: Putting the image in shared memory, using MIT-SHM, using the XPutImage directly on the java canvas with AWT-JNI. nothing will allow me to prevent all the memcpy's and to use only framegrabber/framebuffer resources. i tried to look into using Sun-Dga extension but could not find enough documentation for this. >From what i read and tested, i believe that the good performance in my java-benchmark >app was a result of the jvm (1.4) using dga to actually save all of the >BufferedImages in the frame buffer as dga pixmaps (whatever that means). I know it >for sure, because if i set the environment flag NO_J2D_DGA i get a performace loss of >about 50%, ie instead of ~22fps i get ~12 which is close to the best result i got >using other techniques. What i would be more than happy to have is a "pointer" to the java dga pixmap, which i could give to my framegrabber, and then i would have a BufferedImage which is updated with the video image in "zero" time and then displayed by the jvm in ~22 frames per second. So after this long and frustrating story my questions are: 1. Does what im trying to achieve sounds reasonable? 2. Is there any way in which i can get the "pointer" i mentioned above? Does it exists? 3. Is there any other techniques for displaying live (~22fps) video images from an external capture device (pci framegrabber) in a java application ? or in a native Solaris/Cde X application? Any help would be appreciated Thanks, Adam =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
