Initializing a NEWT Window in Java and Rendering Natively

Greetings everyone!

I have had great success with developing cross-platform applications which render GPU-based simulations in the past using Java to initialize the GUI and native code to render onto the Canvas. However, performance is an important factor in many of the GPGPU algorithms I implement now, and I would like to avoid the latency inherent in using either AWT or JNI by rendering natively using NEWT. This was quite straightforward to accomplish using AWT, since the Java API comes with headers which define functions using which I can obtain an OpenGL context; I was wondering if I could do the same with NEWT, since I could not find any functions with allow for native interoperability. I would be more than happy to contribute some code to accomplish this task if a solution does not currently exist and if doing so would not involve a large undertaking. Whether the case is the former or the latter, would someone please provide me with some more information and point me in the right direction?

Thank you very much for your help!

What do you mean by "native interoperability"? I already display 3D objects written in C++/OpenGL in JOGL applications, I don't see which changes would be necessary to do the same thing in NEWT. On my view, it does not change anything. Am I wrong? Sven could answer you better than me.

On Friday, March 04, 2011 10:47:18 gouessej [via jogamp] wrote:
>
> What do you mean by "native interoperability"? I already display 3D objects
> written in C++/OpenGL in JOGL applications, I don't see which changes would
> be necessary to do the same thing in NEWT. On my view, it does not change
> anything. Am I wrong? Sven could answer you better than me.

I concur Julien, ie I don' get the question either - and your statement is true :)

So with NEWT, it's like with AWT, but without the AWT threading model restrictions.

~Sven

  offtopic:
GPGPU...
have you taken a look at JOCL? GPGPU is more or less dead if you really
mean with GPGPU the (ab)use of shaders for general purpose tasks ;)

(best case: no copy at all, compute and display using the GPU)

best regards,
michael

On 03/04/2011 07:34 AM, void-pointer [via jogamp] wrote:

I only can assume sombody has removed the email/message I was just replying to ..
Too bad I can't see who it was - Please PM me .. and/or don't do this, thx.

Here my reply to the removed email ..

On Saturday, March 05, 2011 01:44:04 void-pointer [via jogamp] wrote:
got you ..

No need to use C API header for NEWT, it's all exposed in Java
in the NativeSurface interface
  http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/nativewindow/NativeSurface.html

Having an instance of NativeSurface, you only need to:

NativeSurface ns = ..

if ( NativeSurface.LOCK_SURFACE_NOT_READY != ns.lockSurface() ) {
  try {
    long surfaceHandle = ns.getSurfaceHandle();

    .. do somethig with the surface handle,
    .. wheather it is via JNI or not ..
  } finally {
    ns.unlockSurfaceHandle();
  }
}

see
  http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/nativewindow/NativeSurface.html#getSurfaceHandle%28%29
  http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/nativewindow/NativeWindow.html#getWindowHandle%28%29

A NativeSurface is implemented with a NEWT Window,
but alsa with an JAWTWindow (AWT Canvas -> NativeWindow).

In JOGL, we only use the NativeWindow/Surface abstraction to have our code
windowing toolkit agnostic.
  http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/nativewindow/NativeWindowFactory.html#getNativeWindow%28java.lang.Object,%20javax.media.nativewindow.AbstractGraphicsConfiguration%29

Using NEWT is of course recommended :)

+++

> @Mr. Bien I should have been more specific when I indicated "GPGPU" - I use
> CUDA to develop my algorithms. Using shaders for general-purpose computation
> would be mind-numbingly painful to say the least 0_o.

Feel free to give JOCL a try!
JOCL is available on jogamp.org as well.

Maybe you can be friends with the idea of using the platform and vendor
independent OpenCL API directly in Java ?
Soon to be available on mobile devices as well.

Of course ... whatever serves you best.

~Sven

Sorry that I deleted my previous post! In retrospect after posting, I thought that I should look more closely at the JOGL API before pestering you with more questions so that I did not bother you unnecessarily. I realized that I may have not understood correctly how the library deals with native surfaces, so I wanted to hold back until after doing some more research. But your post just solved all of my problems - thank you very much for clarifying this! I was actually planning to port to OpenCL soon - I held off previously because of shaky support. I have always used JOGL when developing graphics applications in order to maintain platform compatibility, and will definitely use JOCL as I begin to port the existing code I have written.

Thanks again for your help; I really appreciate it!

On 03/05/2011 01:44 AM, void-pointer [via jogamp] wrote:
> @Mr. Bien I should have been more specific when I indicated "GPGPU" -
> I use CUDA to develop my algorithms. Using shaders for general-purpose
> computation would be mind-numbingly painful to say the least 0_o.
sorry, i misinterpreted your post a little bit. If someone sais GPGPU i
always have the old way of GPGPU in mind. It was quite common to map
parallel tasks to graphical problems to be able to run vendor
independent computational intensive programs on GPUs before techn. like
OpenCL appeared.


> I have always used JOGL when developing graphics applications in order
> to maintain platform compatibility, and will definitely use JOCL as I
> begin to port the existing code I have written.
sounds great. I can only repeat what i said in past on the JOCL mailing
list: API feedback is very appreciated -  if you run into problems or
think certain APIs can be improved/extended, please let us know.

best regards,
michael