OpenGL and Java - comp.graphics.api.opengl

You have to download the java api's to use an OpenGL like functionality in java. There are several packages that can give you this functionality (Java3d, jogl, etc). If you already know Java then the obvious pro is you don't have to learn C or C++ to use OpenGL (which trying to learn OpenGL and C or C++ at the same time can be difficult) Java's implementation of OpenGL does seem to run slower than C or C++ On Jan 23, 10:02 am, "rust" <harsha...@gmail.com> wrote: > Hi guys, > could u ppl tell me how compatible is openGL with java. What are the > pros n cons of using opengl with Java rather than C or C++.

OpenGL (all free) www.lwjgl.org https://jogl.dev.java.net/ http://www.sra.co.jp/people/nisinaka/Jun4Java/index_en.html 3D APIs (all free) http://java.sun.com/products/java-media/3D/ http://xith.org/ Speed ? Comparable to C/C++. Definitely not an issue. Cheers! Mik -- "rust" <harshavar@gmail.com> ha scritto nel messaggio news:1169575329.306990.75240@a75g2000cwd.googlegroups.com... > Hi guys, > could u ppl tell me how compatible is openGL with java. What are the > pros n cons of using opengl with Java rather than C or C++. >

Define "Real-world" and "60% java functionality". Are you thinking of gaming, professional apps, scientific apps, desktop tools ? You're right that it all depends on the application you're creating, but unless you specifically need some good-old pointer math, you can develop a fully featured all-java application with performance in mind. There are tons of commercial games you cannot even suspect they're java based.. Mik -- "A.Cicak" <ovca@hotmail.com> ha scritto nel messaggio news:45b98a23$1@news.bihnet.ba... > >Comparable to C/C++. Definitely not an issue. > In benchmarks maybe, in real world - could be if you plan to program in > Java without using 60% of java functionality. >

It was not my intention to start discussion here C++ vs. Java, after all this is OpenGL channel, I only said what I said because I wanted to advice rust to go for C++. So my advice is C++, not Java if he is going to do graphics programming, esspecialy real time. Only exception is if he already knows Java and does not want to spend time learning new language, and wants to get started with his app ASAP. I mean there are gigabytes of dicussion c++ vs java and I dont think www needs few Kb more of it :).

"A.Cicak" <ovca@hotmail.com> ha scritto nel messaggio >> Comparable to C/C++. Definitely not an issue. I disagree with "not an issue". > In benchmarks maybe, in real world... Agreed. Little benchmarks don't show the real picture. If the word "performance" is *anywhere* in your plans then forget Java. C++ is just as easy to write as Java (I personally think it's easier when you get used to it...) and will always be an order of magnitude faster when working with real-life data, not microbenchmarks. And... OpenGL makes the performance gap even bigger because all OpenGL function calls and all OpenGL data transfers have to go through an extra layer of code to get the raw memory access needed. -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. We�re judging how a candidate will handle a nuclear crisis by how well his staff creates campaign ads. It�s a completely nonsensical process.

"Michele Puccini" <mik@c-l-a-s-s-x.it> wrote in message news:KYZth.20$AU6.31@nntpserver.swip.net... > OpenGL (all free) > > www.lwjgl.org > https://jogl.dev.java.net/ > http://www.sra.co.jp/people/nisinaka/Jun4Java/index_en.html > > 3D APIs (all free) > > http://java.sun.com/products/java-media/3D/ > http://xith.org/ > > Speed ? Comparable to C/C++. Definitely not an issue. > > Cheers! > > Mik > -- > > "rust" <harshavar@gmail.com> ha scritto nel messaggio > news:1169575329.306990.75240@a75g2000cwd.googlegroups.com... >> Hi guys, >> could u ppl tell me how compatible is openGL with java. What are the >> pros n cons of using opengl with Java rather than C or C++. >> > > jogl is probably the most "official" of the bunch; it should be 100% integrated with JAVA 1.6 . -jbw

"fungus" <umailMY@SOCKSartlum.com> wrote in message news:eTNuh.5926$%e5.4668@news.ono.com... > "A.Cicak" <ovca@hotmail.com> ha scritto nel messaggio >>> Comparable to C/C++. Definitely not an issue. > > I disagree with "not an issue". > >> In benchmarks maybe, in real world... > > Agreed. Little benchmarks don't show the real > picture. > > If the word "performance" is *anywhere* in your > plans then forget Java. > > C++ is just as easy to write as Java (I personally > think it's easier when you get used to it...) and > will always be an order of magnitude faster when > working with real-life data, not microbenchmarks. > > And... OpenGL makes the performance gap even bigger > because all OpenGL function calls and all OpenGL > data transfers have to go through an extra layer > of code to get the raw memory access needed. > > > -- > <\___/> > / O O \ > \_____/ FTB. For email, remove my socks. > > > We�re judging how a candidate will handle a nuclear > crisis by how well his staff creates campaign ads. > It�s a completely nonsensical process. Order of magnitude is way, way off. JAVA might be slower if you do naive silly things. It can be nearly as fast as C++. And a whole, whole lot easier to maintain, and debug (especially memory problems). For the specific case of JAVA and OpenGL, and using vertex buffer objects for most geometry, Java is just as fast for graphics and definitely a whole lot simpler. jbw

"fungus" <umailMY@SOCKSartlum.com> ha scritto nel messaggio news:eTNuh.5926$%e5.4668@news.ono.com... > "A.Cicak" <ovca@hotmail.com> ha scritto nel messaggio >>> Comparable to C/C++. Definitely not an issue. > And... OpenGL makes the performance gap even bigger > because all OpenGL function calls and all OpenGL > data transfers have to go through an extra layer > of code to get the raw memory access needed. Ahem.. which java version you're referring to ? JDK 1.02 was released in 1996, if I remember. In modern OpenGL for Java implementations java-side data buffers are shared with OpenGL/native through Java NIO (see java.nio Direct Buffers). also plase take a look here: http://java.sun.com/products/jfc/tsc/articles/jcanyon/ If you're referring to some JNI native call overhead then you maybe right, but remember to think in terms of pure processor clock ticks. A whole application would not suffer too much from such kind of indirection. I remember than a pure virtual C++ call is much slower than the java couterpart, but no one in the C++ world will complain for this. Cheers, Mik --

Michele Puccini wrote: > > In modern OpenGL for Java implementations java-side data buffers are shared > with OpenGL/native through Java NIO (see java.nio Direct Buffers). > Ok, maybe I'm out of touch. Still, that only solves one of the problems which makes Java slower. > a pure virtual C++ call is much slower than the java > couterpart, but no one in the C++ world will complain for this. > A C++ virtual call fetches the function pointer from a little table and that's it. If the object's vtable is in main cache on a modern, long-pipeline CPU the the overhead for a virtual call will be precisely zero (the look-ahead logic is constantly looking ahead for subroutine calls and deletes them before they ever reach the execution unit). -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. We�re judging how a candidate will handle a nuclear crisis by how well his staff creates campaign ads. It�s a completely nonsensical process.

"fungus" <umailMY@SOCKSartlum.com> wrote in message news:yGovh.6421$%e5.4914@news.ono.com... > Michele Puccini wrote: >> >> In modern OpenGL for Java implementations java-side data buffers are >> shared with OpenGL/native through Java NIO (see java.nio Direct Buffers). >> > > Ok, maybe I'm out of touch. > > Still, that only solves one of the problems which > makes Java slower. > >> a pure virtual C++ call is much slower than the java couterpart, but no >> one in the C++ world will complain for this. >> > > A C++ virtual call fetches the function pointer from > a little table and that's it. > > If the object's vtable is in main cache on a modern, > long-pipeline CPU the the overhead for a virtual call > will be precisely zero (the look-ahead logic is > constantly looking ahead for subroutine calls and > deletes them before they ever reach the execution > unit). > > > -- > <\___/> > / O O \ > \_____/ FTB. For email, remove my socks. > > > We�re judging how a candidate will handle a nuclear > crisis by how well his staff creates campaign ads. > It�s a completely nonsensical process. The same can be said (RE cacheing) about a JIT-compiled byte code. JAVA is demonstrably very very fast when well done; all sorts of numerical benchmarks prove it. Function overhead is nearly on a par with C++ functions; any major amount of data in OpenGL is via NIO buffers that do not get copied (VBO's especially, which we all use now, right ?). There are many Xith and JOGL demos that clearly show very fast JAVA OpenGL. There are also many badly written, leaky, crashy, nonportable and unsupportable C++ OpenGL codes. Bottom line: If your OpenGL app is slow, blame the design & implementation of the app, not the language it's written in. jbw