Nabble - general

Re: JInput (JXInput) over haul.

2012-05-10T03:50:54Z

Hey

You can look at Ardor3D, it supports both JOGL and JInput, you can look at its source code to understand how it works. The webpage of JXInput claims wrong things, JNI is not slow and JXInput is not really 100% pure Java library which is not a problem anyway.

JXInput has a poorer support of GNU Linux, I prefer JInput. I plan to use it but I would like to modify it to use the same automatic extraction of native libraries from JARs than all JogAmp APIs. I can't work on it now as my players are still waiting for being able to kill people in the pre-beta-version of TUER as you may know

Good luck.

Julien Gouesse
http://tuer.sourceforge.net
http://gouessej.wordpress.com

Android Market / Google Play Builds Available

2012-05-09T23:32:33Z

Hi All,

yesterday post RC8 builds were made available in the Android Market (Google Play).

As you know we have split up the JogAmp modules in APKs:
- Launcher
- GlueGen
- JOGL
- JOGL Tests

Later JOAL, JOCL, .. will follow.

Hence one would need to install all APKs .. we may think about the
inconvenience .. maybe it's possible to install a bunch of APKs at once.

The list of APK URLs is referenced here:
http://jogamp.org/wiki/index.php/Android_Packages

Here are the URLs:
https://play.google.com/store/apps/details?id=jogamp.android.launcher
https://play.google.com/store/apps/details?id=com.jogamp.common
https://play.google.com/store/apps/details?id=javax.media.opengl
https://play.google.com/store/apps/details?id=com.jogamp.opengl.test

Cheers, Sven

JInput (JXInput) over haul.

2012-05-09T13:00:19Z

CONTENTS DELETED

The author has deleted this message.

Release v2.0-rc8

2012-05-02T06:29:10Z

Posted via web interface, 2nd try, email didn't get through ..

+++

'Hot-Fixes': JOGL: Windows Firefox and Chrome crashes, OSX Applet crashes for detached NEWT Window.

http://jogamp.org/wiki/index.php/Release_2.0-rc8
http://jogamp.org/deployment/v2.0-rc8/
http://jogamp.org/deployment/v2.0-rc8/archive/jogamp-all-platforms.7z

JOGL ChangeLog:
Bug 577: Disable debug message XInitThreads() called (only enabled in native debug mode).
WWW: Add GeoGebra; Prio JOGL2 usage
WWW: Cleanup some descriptions, text alignment
NEWT Input- Mouse-Event: Consitency of mouse button number; Add button -> button-mask func.
Fix Bug 571: X11 behavior, where the PRESSED button is not included in the native mask.
test scripts
TestGearsES2NEWT: fullscreen/above toggle print fullscreen/above state always
Bug 570: NEWT General/X11: Decouple setFullscreen() and setAlwaysOnTop(); Use window-static instances for runnable actions
Bug 556: Newt Mouse Synthetic Drag Event: Clear state if mouse enters/leaves window.
EGLGraphicsConfigurationFactory: Add 'unregisterFactory()' static entry allowing to remove EGL/ES based factory
GLProfile/EGLDrawableFactory: Detect ANGLE (Windows D3D ES2 Emulation) and disable support per default.
NEWT/WindowImpl: Make all 'action' class instances final; Action's init() determines whether it shall be executed.
Fix Bug 560 and NEWT window closing behavior in general for all platforms.
JOGLNewtAppletBase: Minor cleanup
NEWT: Revert static/locked action instances due to possible deadlocks; class Window.ReparentAction -> enum Window.ReparentOperation
Complete commit c9faebb8f8f6be4c0de4919a516b4692742bc13c: Use 'enum ReparentOperation' in test.
NEWT API Change 'WindowClosingProtocol': Use 'enum WindowClosingMode' instead of static final int values.
Test MovieCube: Allow recreation - Video is still not visible after recreation (detach window) on OSX (FF, Safari)
NEWT/OSX: Fix occasional crash 'free of non allocated object' - change window order on main-thread.

~Sven

Release v2.0-rc8

2012-05-02T06:21:26Z

'Hot-Fixes': JOGL: Windows Firefox and Chrome crashes, OSX Applet crashes for detached NEWT Window.

http://jogamp.org/wiki/index.php/Release_2.0-rc8
http://jogamp.org/deployment/v2.0-rc8/
http://jogamp.org/deployment/v2.0-rc8/archive/jogamp-all-platforms.7z

JOGL ChangeLog:
Bug 577: Disable debug message XInitThreads() called (only enabled in native debug mode).
WWW: Add GeoGebra; Prio JOGL2 usage
WWW: Cleanup some descriptions, text alignment
NEWT Input- Mouse-Event: Consitency of mouse button number; Add button -> button-mask func.
Fix Bug 571: X11 behavior, where the PRESSED button is not included in the native mask.
test scripts
TestGearsES2NEWT: fullscreen/above toggle print fullscreen/above state always
Bug 570: NEWT General/X11: Decouple setFullscreen() and setAlwaysOnTop(); Use window-static instances for runnable actions
Bug 556: Newt Mouse Synthetic Drag Event: Clear state if mouse enters/leaves window.
EGLGraphicsConfigurationFactory: Add 'unregisterFactory()' static entry allowing to remove EGL/ES based factory
GLProfile/EGLDrawableFactory: Detect ANGLE (Windows D3D ES2 Emulation) and disable support per default.
NEWT/WindowImpl: Make all 'action' class instances final; Action's init() determines whether it shall be executed.
Fix Bug 560 and NEWT window closing behavior in general for all platforms.
JOGLNewtAppletBase: Minor cleanup
NEWT: Revert static/locked action instances due to possible deadlocks; class Window.ReparentAction -> enum Window.ReparentOperation
Complete commit c9faebb8f8f6be4c0de4919a516b4692742bc13c: Use 'enum ReparentOperation' in test.
NEWT API Change 'WindowClosingProtocol': Use 'enum WindowClosingMode' instead of static final int values.
Test MovieCube: Allow recreation - Video is still not visible after recreation (detach window) on OSX (FF, Safari)
NEWT/OSX: Fix occasional crash 'free of non allocated object' - change window order on main-thread.

~Sven

signature.asc (910 bytes) Download Attachment

Re: Release v2.0-rc7

2012-04-30T04:13:19Z

On 04/27/2012 04:01 PM, gouessej [via jogamp] wrote:
> Hi
>
> Please run the autobuilds so that I can benefit of the most recent fixes that
> are really useful for us.

Will do .. currently I need the windows test machine to figure out the
regression where on win-32bit applets don't work reliable.

~Sven

signature.asc (910 bytes) Download Attachment

Re: Release v2.0-rc7

2012-04-27T07:01:09Z

Hi

Please run the autobuilds so that I can benefit of the most recent fixes that are really useful for us.

Julien Gouesse
http://tuer.sourceforge.net
http://gouessej.wordpress.com

Release v2.0-rc7

2012-04-25T08:05:07Z

http://jogamp.org/wiki/index.php/Release_2.0-rc7

done works here ..

On 04/25/2012 01:44 PM, Sven Gothel wrote:

> http://jogamp.org/wiki/index.php/Release_2.0-rc6
>
> Today we released v2.0-rc6,
> it was a bit bumpy to get there.
>
> I broke the binaries today for about 4 hours,
> due to pack200 bug 5078608
> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5078608>
>
> BTW .. it seems that this pack200 bug was also triggered
> w/ previous releases, at least RC5. Hence this release will
> be safe for our deployment.
>
> Further more we have a regression throwing a security exception
> while trying to read property 'java.awt.headless' early on.
> A fix is already on the way and will be published as rc7 ASAP.
>
> Other than this .. I guess RC7 will be great :)
>
> Cheers, Sven

--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; fax : +49 (471) 4707741
Timezone CET: PST+9, EST+6, UTC+1

signature.asc (910 bytes) Download Attachment

Release v2.0-rc6 (v2.0-rc7 will followup soon)

2012-04-25T04:44:54Z

http://jogamp.org/wiki/index.php/Release_2.0-rc6

Today we released v2.0-rc6,
it was a bit bumpy to get there.

I broke the binaries today for about 4 hours,
due to pack200 bug 5078608
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5078608>

BTW .. it seems that this pack200 bug was also triggered
w/ previous releases, at least RC5. Hence this release will
be safe for our deployment.

Further more we have a regression throwing a security exception
while trying to read property 'java.awt.headless' early on.
A fix is already on the way and will be published as rc7 ASAP.

Other than this .. I guess RC7 will be great :)

Cheers, Sven
--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; fax : +49 (471) 4707741
Timezone CET: PST+9, EST+6, UTC+1

signature.asc (910 bytes) Download Attachment

Re: Loading libraries from an executable JAR is seriously hard.

2012-04-05T10:41:32Z

On 04/05/2012 01:41 PM, bkuker [via jogamp] wrote:

>
>
> Thank you, I must have misunderstood:
>
>> I guess it's time to remove the per platform archive files
>> in favor of the all-platform one.
>
>> Will keep the native libraries in there,
>> however we may remove it's reference from the wiki (howto, guides, etc)
>> or at least mark them as *alternative*. They cost lots of confusions.
>
>>From another thread.

That was regarding the platform 7z archive file, not JAR files.

>
> I'll keep trying to find a way forward with the fat jar, before trying to
> convince the upstream project to switch to jar-in-jar, but the takeaway for
> now is that JOGL prefers a jar-in-jar as the solution for a single file
> executable jar.
>
>> However, the fat JAR can be achieved with the current API model, yes.
>
> Do you mean this with or without changes to the JogAmp libraries themselves?

Yes, we need to make changes in GlueGen to support that.
I merely mentioned that we don't need to change the API
or anything to achieve that feature.

Please put all these emails in a bugreport (our bugzilla), thank you.

~Sven

signature.asc (910 bytes) Download Attachment

Re: Loading libraries from an executable JAR is seriously hard.

2012-04-05T04:41:11Z

Thank you, I must have misunderstood:

> I guess it's time to remove the per platform archive files
> in favor of the all-platform one.

> Will keep the native libraries in there,
> however we may remove it's reference from the wiki (howto, guides, etc)
> or at least mark them as *alternative*. They cost lots of confusions.

From another thread.

I'll keep trying to find a way forward with the fat jar, before trying to convince the upstream project to switch to jar-in-jar, but the takeaway for now is that JOGL prefers a jar-in-jar as the solution for a single file executable jar.

> However, the fat JAR can be achieved with the current API model, yes.

Do you mean this with or without changes to the JogAmp libraries themselves?

Re: Loading libraries from an executable JAR is seriously hard.

2012-04-05T03:40:34Z

On 04/05/2012 11:53 AM, bkuker [via jogamp] wrote:
>
>
> It sounds from some other posts like you are planing to drop the architecture
> specific jars in favor of one all-encompassing JAR.

I never said that - nope. I especially emphasized that the platform specific
native JARs are very efficient when it comes to networking (Applets ..).

However, I am open to give the fat-jar method a thought as a fall-back.

> If that is the case I

[as a fall-back]

> would assume you are going to have to use architecture specific directories
> anyway?
>
> [arch]/[libname].[so,dll,whatever]

as I mentioned .. yes

>
> Currently it looks like the code goes:
>
> 1. Try to load library from natives jar in same location as gluegen jar.
> 2. Try to load library from library.path
>
> could it be as simple as:
>
> 1. Try to load library from natives jar in same location as gluegen jar.
> 2. Try to load library from
> SomeJogAmpClass.class.getClassLoader().getResource([arch]/[library]).
> 3. Try to load library from library.path
>
> I assume once you have an input stream for the library you can copy it to
> whatever temp place it goes to and loadLibrary(). Resources are commonly
> used, easy to understand, and in a pinch if someone needed to do something
> crazy in a standalone app they could do it with a custom classloader.
>

A custom ClassLoader has it's own restrictions here,
hence I chose to use specific GlueGen methods to utilize this functionality.
For example in an IDE or Applet environment we cannot guarantee an entry point
where a user switches to a new ClassLoader, we provide. Note that native
libraries, static data and classes are only valid from the loading ClassLoader.

We have somehow solved this problem in Android, but it's quite tricky
and we don't want to force people to deal with such problems.

However, the fat JAR can be achieved with the current API model, yes.

~Sven

signature.asc (910 bytes) Download Attachment

Re: Loading libraries from an executable JAR is seriously hard.

2012-04-05T02:53:45Z

It sounds from some other posts like you are planing to drop the architecture specific jars in favor of one all-encompassing JAR. If that is the case I would assume you are going to have to use architecture specific directories anyway?

[arch]/[libname].[so,dll,whatever]

Currently it looks like the code goes:

1. Try to load library from natives jar in same location as gluegen jar.
2. Try to load library from library.path

could it be as simple as:

1. Try to load library from natives jar in same location as gluegen jar.
2. Try to load library from SomeJogAmpClass.class.getClassLoader().getResource([arch]/[library]).
3. Try to load library from library.path

I assume once you have an input stream for the library you can copy it to whatever temp place it goes to and loadLibrary(). Resources are commonly used, easy to understand, and in a pinch if someone needed to do something crazy in a standalone app they could do it with a custom classloader.

Re: Loading libraries from an executable JAR is seriously hard.

2012-04-04T17:14:44Z

On 04/04/2012 11:46 PM, bkuker [via jogamp] wrote:

>
>
> I am trying to use JOGL (2.0 rc5) in a standalone Java app run from an
> executable JAR.
>
> The app's jar is packaged by re-zipping all of the libraries into one fat
> jar. It's not my app, I can't change that.
>
> The JogAmp projects do seem to know how to pull a native library out of a
> JAR (I assume they write it to a temp directory), but the way they find that
> resource seems really complex... It looks for the JAR that GlueGen came in,
> then looks for a jar in the same directory, using a naming convention
> including the architecture, and then gets native libraries from that jar.
>
> This makes it really tough to package it into a single far jar. The eclipse
> jars-in-a-jar method works, but the "fat jar" method does not.
>

Very good assessment & description, thank you.

> Is there any way I can just put the natives in my Jar, and give them to
> GlueGen & JOGL as streams (getResourceFromStream) or some such?

Not as it is today, but we may add something to serve such a need.

Currently the only way to determine the right JAR file for each platform
is the JAR file name - as you pointed out correctly.

The native plain library files itself don't have a unique name.

The current schema, one native JAR file per platform very well
serves the traditional Applet/Webstart deployment since it saves
bandwidth and it also serves most stand alone application.

Having a fat JAR would at least require the native libraries to reside
in a subfolder using our naming convention.
Such implementation would be doable with minor changes to the current code.

However, I don't see a conflict w/ Jar in Jar, which I personally would favor
here. It also gives one the opportunity to use
the original [signed] JAR files, so you can maintain the files
origin and identity.

Well, using a fat JAR here implies that in the JOGL layer,
the fat JAR content is already 'known' and available to the classloader.
Hence we can skip extracting files, but 'just' need to find the platform's
subfolder and continue there (copy files to temp folder and allow them to
loaded by the classloader).
We may even be able to skip the copy part, if it is ensured that only one
ClassLoader will access those libraries (no Applets .. ).

Anybody out there who cannot live with the current use case,
restricted to native Jar files per platform incl. Jar-In-Jar ?

For sure this won't be done for RC6.
Please add a bugreport (enhancement) with the content of your and my writings
and we can vote/discuss it further.

Thank you.

Cheers, Sven

signature.asc (910 bytes) Download Attachment

Loading libraries from an executable JAR is seriously hard.

2012-04-04T14:46:39Z

I am trying to use JOGL (2.0 rc5) in a standalone Java app run from an executable JAR.

The app's jar is packaged by re-zipping all of the libraries into one fat jar. It's not my app, I can't change that.

The JogAmp projects do seem to know how to pull a native library out of a JAR (I assume they write it to a temp directory), but the way they find that resource seems really complex... It looks for the JAR that GlueGen came in, then looks for a jar in the same directory, using a naming convention including the architecture, and then gets native libraries from that jar.

This makes it really tough to package it into a single far jar. The eclipse jars-in-a-jar method works, but the "fat jar" method does not.

Is there any way I can just put the natives in my Jar, and give them to GlueGen & JOGL as streams (getResourceFromStream) or some such?

Re: Implementing JOGL

2012-03-27T02:24:27Z

I don't know how you contribute to GeoTools but if your contribution is public, please don't do anything to prevent a wider support of other operating systems which is very easy with JOGL.

Julien Gouesse
http://tuer.sourceforge.net
http://gouessej.wordpress.com

Re: Implementing JOGL

2012-03-26T06:27:01Z

Thanks for your input. I will see what I can do today. Since this is such a big task trying to integrate JOGL into GeoTools I just want to make sure I have JOGL installed and running properly before starting to change the GeoTools code. Because of the limitations of GeoTools my only practical approach is to develop a desktop swing application. Even the Swing code is considered "unsupported".

So I'm on my own in this endeavor. The application will not be successful without hardware acceleration. And I need to have a working demo by mid-July. Seems like a long time out, but it will be here before I know it. And a lot of this is totally new to me. I am a J2EE developer for the most part.

Luckily this has no requirement to be portable. The ONLY platform it will run on is Windows. So I can just concentrate on that.

Thanks again.

Re: Implementing JOGL

2012-03-25T15:20:27Z

On 03/25/2012 06:59 PM, glennp [via jogamp] wrote:
>
> I am developing on Win 7 32-bit so I downloaded the i586 version. Now I am
> trying to run the test_dbg bat file. I do get a window briefly displayed.
> But the log file contains all sorts of errors.

The log file snippets you showed were not error
but a very verbose runtime trace, helping us to understand why
JOGL may not work, i.e. certains assumptions were not matched.

Try test.bat, which doesn't include the verbose traces.
If all goes well, you should see some verbose information of
available OpenGL profiles and some platform information.

> Obviously I do not have the
> run time environment set up properly. I tried going with the JOGL
> Userguide, but it does say it is out of date. I have tried searching for
> more up to date instructions but can't find anything.

The userguide itself states it's out of date (currently under review
in our git repository) .. as Wade stated, pls check the Wiki.

>
> Could someone please outline the proper installation for the latest version
> of JOGL?

You can 'simply' check the JOGL test applets to see how the online deployment
works .. again - wiki pages are very thoroughly (Eclipse, Applets, Webstart,
Netbeans, ...) - thanks to Wade and others.

Of course .. even the Wiki does not catch all the newt stuff we work on
but sooner or later .. somebody will fix them :)

Hope this helps a bit.

Cheers, Sven

signature.asc (910 bytes) Download Attachment

Re: Implementing JOGL

2012-03-25T11:49:56Z

I wouldn't advise looking at the test.bat file -- it seems to be just for the use of the developers, and can be left in unpredictable states on check-in Those error messages you're seeing are just diagnostic output, not necessarily real errors.

To download and install JOGL, see this: http://jogamp.org/wiki/index.php/Downloading_and_installing_JOGL
To set up a JOGL project in your favorite IDE or on the command line, see this: http://jogamp.org/wiki/index.php/Downloading_and_installing_JOGL
For some tutorials, see this: http://jogamp.org/wiki/index.php/Jogl_Tutorial

Let me know if there are errors on any of these wiki pages; if so, I will fix them.

Implementing JOGL

2012-03-25T09:59:08Z

I am in the process of developing a desktop mapping application using GeoTools. It will only run on Windows. I need to use hardware acceleration in order to make this application work properly. In researching Open GL it seems that the Java world relies on JOGL to accomplish this.

I am developing on Win 7 32-bit so I downloaded the i586 version. Now I am trying to run the test_dbg bat file. I do get a window briefly displayed. But the log file contains all sorts of errors. Obviously I do not have the run time environment set up properly. I tried going with the JOGL Userguide, but it does say it is out of date. I have tried searching for more up to date instructions but can't find anything.

Could someone please outline the proper installation for the latest version of JOGL?

After it first failed I did make some modifications to the bat file based on what I saw in the Userguide. Here is what I am trying to run:

set path=D:\java\jogamp-windows-i586\lib;%PATH%
set BLD_DIR=D:\java\jogamp-windows-i586\jar

set CP_ALL=.;%BLD_DIR%\gluegen-rt.jar;%BLD_DIR%\jogl.all.jar;%BLD_DIR%
echo CP_ALL %CP_ALL%

set D_ARGS="-Djogamp.debug=all" "-Dnativewindow.debug=all" "-Djogl.debug=all" "-Dnewt.debug=all"
set X_ARGS="-Dsun.java2d.noddraw=true" "-Dsun.awt.noerasebackground=true"

java -classpath %CP_ALL% %X_ARGS% %D_ARGS% com.jogamp.newt.opengl.GLWindow >> test_dbg.log 2>&1

I do get a lot of output. Evidently it is verifying that it can access all the proper jar and DLL files.

The first error I find in the log is:

JNILibLoaderBase: loaded gluegen-rt
java.lang.Exception: JVMUtil.initSingleton() .. initialized main
	at jogamp.common.jvm.JVMUtil.<clinit>(JVMUtil.java:62)
	at com.jogamp.common.os.Platform.<clinit>(Platform.java:215)
	at com.jogamp.common.util.VersionUtil.getPlatformInfo(VersionUtil.java:54)
	at com.jogamp.common.util.VersionUtil.getPlatformInfo(VersionUtil.java:82)
	at com.jogamp.newt.opengl.GLWindow.main(GLWindow.java:909)

Then I get:

GLProfile.initSingleton(firstUIActionOnProcess: false) - thread main
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Thread.java:1249)
	at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:117)
	at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:151)
	at javax.media.opengl.GLProfile.getProfileMap(GLProfile.java:1688)
	at javax.media.opengl.GLProfile.get(GLProfile.java:652)
	at javax.media.opengl.GLProfile.getDefault(GLProfile.java:478)
	at javax.media.opengl.GLProfile.getDefault(GLProfile.java:486)
	at com.jogamp.newt.opengl.GLWindow.main(GLWindow.java:913)

And little later I get:

java.lang.Throwable: main - Info: NativeWindowFactory.<init>
	at javax.media.nativewindow.NativeWindowFactory.<clinit>(NativeWindowFactory.java:138)
	at javax.media.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1214)
	at javax.media.opengl.GLProfile.access$000(GLProfile.java:75)
	at javax.media.opengl.GLProfile$1.run(GLProfile.java:133)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:122)
	at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:151)
	at javax.media.opengl.GLProfile.getProfileMap(GLProfile.java:1688)
	at javax.media.opengl.GLProfile.get(GLProfile.java:652)
	at javax.media.opengl.GLProfile.getDefault(GLProfile.java:478)
	at javax.media.opengl.GLProfile.getDefault(GLProfile.java:486)
	at com.jogamp.newt.opengl.GLWindow.main(GLWindow.java:913)

And on down the log I find:


GLDrawableFactory.static - Native OS Factory for: Windows: jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory
main - DynamicLibraryBundle.init start with: jogamp.opengl.windows.wgl.WindowsWGLDynamicLibraryBundleInfo
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Thread.java:1249)
	at com.jogamp.common.os.DynamicLibraryBundle.<init>(DynamicLibraryBundle.java:82)
	at jogamp.opengl.GLDynamicLookupHelper.<init>(GLDynamicLookupHelper.java:36)
	at jogamp.opengl.DesktopGLDynamicLookupHelper.<init>(DesktopGLDynamicLookupHelper.java:37)
	at jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory.<init>(WindowsWGLDrawableFactory.java:93)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at com.jogamp.common.util.ReflectionUtil.createInstance(ReflectionUtil.java:166)
	at com.jogamp.common.util.ReflectionUtil.createInstance(ReflectionUtil.java:188)
	at com.jogamp.common.util.ReflectionUtil.createInstance(ReflectionUtil.java:208)
	at com.jogamp.common.util.ReflectionUtil.createInstance(ReflectionUtil.java:230)
	at javax.media.opengl.GLDrawableFactory.initSingletonImpl(GLDrawableFactory.java:150)
	at javax.media.opengl.GLDrawableFactory.initSingleton(GLDrawableFactory.java:115)
	at javax.media.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1244)
	at javax.media.opengl.GLProfile.access$000(GLProfile.java:75)
	at javax.media.opengl.GLProfile$1.run(GLProfile.java:133)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:122)
	at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:151)
	at javax.media.opengl.GLProfile.getProfileMap(GLProfile.java:1688)
	at javax.media.opengl.GLProfile.get(GLProfile.java:652)
	at javax.media.opengl.GLProfile.getDefault(GLProfile.java:478)
	at javax.media.opengl.GLProfile.getDefault(GLProfile.java:486)
	at com.jogamp.newt.opengl.GLWindow.main(GLWindow.java:913)

And then I start getting X11 errors. This I don't understand since I am running on Windows. I thought X11 is for Linux. Here is the start of the errors:

JNILibLoaderBase: loadLibraryInternal(nativewindow_x11) -> TempJarCache not mapped
JNILibLoaderBase: loadLibraryInternal(nativewindow_x11) -> System.loadLibrary(nativewindow_x11)
java.lang.UnsatisfiedLinkError: no nativewindow_x11 in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1734)
	at java.lang.Runtime.loadLibrary0(Runtime.java:823)
	at java.lang.System.loadLibrary(System.java:1028)
	at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:318)
	at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:55)
	at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:85)
	at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:215)
	at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:365)
	at com.jogamp.common.os.DynamicLibraryBundle.loadLibraries(DynamicLibraryBundle.java:274)
	at com.jogamp.common.os.DynamicLibraryBundle.<init>(DynamicLibraryBundle.java:87)
	at jogamp.opengl.GLDynamicLookupHelper.<init>(GLDynamicLookupHelper.java:36)
	at jogamp.opengl.DesktopGLDynamicLookupHelper.<init>(DesktopGLDynamicLookupHelper.java:37)
	at jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory.<init>(WindowsWGLDrawableFactory.java:93)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at com.jogamp.common.util.ReflectionUtil.createInstance(ReflectionUtil.java:166)
	at com.jogamp.common.util.ReflectionUtil.createInstance(ReflectionUtil.java:188)
	at com.jogamp.common.util.ReflectionUtil.createInstance(ReflectionUtil.java:208)
	at com.jogamp.common.util.ReflectionUtil.createInstance(ReflectionUtil.java:230)
	at javax.media.opengl.GLDrawableFactory.initSingletonImpl(GLDrawableFactory.java:150)
	at javax.media.opengl.GLDrawableFactory.initSingleton(GLDrawableFactory.java:115)
	at javax.media.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1244)
	at javax.media.opengl.GLProfile.access$000(GLProfile.java:75)
	at javax.media.opengl.GLProfile$1.run(GLProfile.java:133)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:122)
	at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:151)
	at javax.media.opengl.GLProfile.getProfileMap(GLProfile.java:1688)
	at javax.media.opengl.GLProfile.get(GLProfile.java:652)
	at javax.media.opengl.GLProfile.getDefault(GLProfile.java:478)
	at javax.media.opengl.GLProfile.getDefault(GLProfile.java:486)
	at com.jogamp.newt.opengl.GLWindow.main(GLWindow.java:913)
Info: Could not load JNI/Glue library: nativewindow_x11

And then I start getting a huge list of failed lookups. Here is just a small list:

Lookup-Native: <glMapBuffer> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferARB> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferGL2> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferOES> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferKHR> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferOML> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBuffer3DFX> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferAMD> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferANGLE> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferARM> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferAPPLE> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferATI> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferEXT> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferHI> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferHP> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferIBM> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferIMG> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferMESA> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferMESAX> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferNV> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]
Lookup-Native: <glMapBufferQCOM> ** FAILED ** in libs [NativeLibrary[OpenGL32.dll, 0x66740000, global false]]

I'll stop here. I don't know what to do to fix this. Could someone please give me some instructions on what is wrong and how I go about fixing it?

I do greatly appreciate any feedback to help get me past this!!

Re: write/convert JOGL animation to .mov or .wmv or ogg

2012-03-04T11:22:53Z

On 03/04/2012 08:00 PM, Demoscene Passivist [via jogamp] wrote:

>
>
> U can use the utility class com.jogamp.opengl.util.awt.Screenshot. With the
> method Screenshot.readToBufferedImage() u can read the rendered image back
> from the GPU and convert it to a BufferedImage.
>
> Stg like this:
>
>
> The BufferedImage can then be easily writte to a PNG:
>

If I may advertise the AWT free utility GLReadBufferUtil here :
<http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/com/jogamp/opengl/util/GLReadBufferUtil.java;hb=HEAD#l55>
Test Case:
<http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/util/TestGLReadBufferUtilTextureIOWrite02NEWT.java;hb=HEAD#l65>

It's tested on ES2 w/o AWT (tga snapshots).

~Sven

>
> Do that for every frame and u get an image-sequence. Name them
> "image_0000.png"-"image_1000.png". The images can then be easily converted
> with ffmpeg or mencoder.
>
> U may take a look at https://github.com/demoscenepassivist/SocialCoding my
> repository for
> https://github.com/demoscenepassivist/SocialCoding/tree/master/build_demos_jogamp
> a couple of batch scripts that do the conversion.

signature.asc (910 bytes) Download Attachment

Re: write/convert JOGL animation to .mov or .wmv or ogg

2012-03-04T11:00:32Z

U can use the utility class com.jogamp.opengl.util.awt.Screenshot. With the method Screenshot.readToBufferedImage() u can read the rendered image back from the GPU and convert it to a BufferedImage.

Stg like this:

BufferedImage tScreenshot = Screenshot.readToBufferedImage(0,0, getScreenWidth(), getScreenHeight(),false);

The BufferedImage can then be easily writte to a PNG:

ImageIO.write(inBufferedImage, "png", tScreenCaptureImageFile);

Do that for every frame and u get an image-sequence. Name them "image_0000.png"-"image_1000.png". The images can then be easily converted with ffmpeg or mencoder.

U may take a look at my repository for a couple of batch scripts that do the conversion.

write/convert JOGL animation to .mov or .wmv or ogg

2012-03-04T08:55:22Z

I am an experienced Java programmer but 100% clueless as to graphics programming, so this may sound dumb, but anyway ...

All tutorials I''ve encountered talk about displaying OpenGL/JOGL apps in an applet or native window, but how do I output the result of my programming to some video format? So I can upload it to YouTUBE or Vimeo, for example. You _DO_ see a lot of JOGL examples on YouTUBE, so it must be possible, but I haven't been able to figure out how.

Is there, for example, something like an OggStream class somewhere, that you can somehow write your frame buffer to, or something?

Re: Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

2012-02-28T13:18:43Z

On 02/28/2012 10:15 PM, Sven Gothel wrote:
> On 02/28/2012 09:22 PM, Wade Walker [via jogamp] wrote:
>>
>>
>> Congratulations on the working ARM v7 builds! Hopefully I'll get a chance to
>> try this for myself soon
>>
>> But how are you compiling JOCL on ARM Linux? I didn't think there was a
>> driver available yet.

:)

Ok .. guess I need to get glasses and not only see JOGL around here.

We can create / compile bindings to anything, even w/o native libraries,
since they get dynamically loaded and looked-up at runtime :)

So if you try to test it .. it will fail ( we don't ).

But .. if the desired ARM T604 w/ OpenCL support arrives
here w/ a native library for OpenCL [Android or 'true' Linux]
we finally can test it.

~Sven

signature.asc (910 bytes) Download Attachment

Re: Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

2012-02-28T13:15:01Z

On 02/28/2012 09:22 PM, Wade Walker [via jogamp] wrote:
>
>
> Congratulations on the working ARM v7 builds! Hopefully I'll get a chance to
> try this for myself soon
>
> But how are you compiling JOCL on ARM Linux? I didn't think there was a
> driver available yet.

CPU == ARM
GPU == OMAP[34] or Tegra2

Ubuntu/ARM + graphics extras ..

https://wiki.ubuntu.com/ARM/OMAP

https://wiki.ubuntu.com/ARM/OMAP/Graphics

https://wiki.ubuntu.com/ARM/TEGRA/AC100

Yup, ARM/Mali400 or better is not supported by ARM on GNU/Linux.
And lately open source folks even started to reverse engineer the
binary blob w/ Linaro involved (ARM is a member .. duh).

Quite an odd .. very odd situation here I would say,
probably due to weirdo politics and some lack of commitment.

Well, it's not the end of all days, so I hope ARM will
either support GNU/Linux w/ a proper binary blob (like NV/AMD/Ti/..),
or maybe even open up the programming specs.

Cheers, Sven

signature.asc (910 bytes) Download Attachment

Re: Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

2012-02-28T12:22:57Z

Congratulations on the working ARM v7 builds! Hopefully I'll get a chance to try this for myself soon

But how are you compiling JOCL on ARM Linux? I didn't think there was a driver available yet.

Re: Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

2012-02-28T03:04:32Z

On my N9 I used JamVM in combination with OpenJDK 6/IcedTea6 1.10.4.
I cross compiled this build using openembedded-classic, I have updated the IcedTea cross compile instructions to also cover the new meta-oe build recipes based on the Yocto project.
http://icedtea.classpath.org/wiki/CrossCompileFaq

If you like to test OpenJDK/IcedTea on the N9 today I recommend you to download and repackage the Debian or Ubuntu produced armel deb/binarys for openjdk-6 and put them inside the N9.
Debian armel debs: http://packages.debian.org/search?suite=wheezy&arch=armel&searchon=names&keywords=openjdk-6

1. First install all the armel debian openjdk-6 packages, preferably on a Debian wheezy/sid machine.
2. cd /usr/lib/jvm
3. cp -Lr java-6-openjdk-armel java-6-openjdk-armel-N9
4. tar zcvf java-6-openjdk-armel-N9.tar.gz java-6-openjdk-armel-N9
5. copy java-6-openjdk-armel-N9.tar.gz to the phone
6. on the phone use devel-su to gain root and unpack the file inside /usr/lib/jvm
7. add symlinks for java javac etc inside /usr/bin
done

Re: Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

2012-02-28T01:25:37Z

On 02/28/2012 10:12 AM, gouessej [via jogamp] wrote:

>
>
> Hi
>
> As far as I know, OpenJDK works better on some distros especially with
> applets for unknown reasons. I have never had any problem under Cent OS, Red
> Hat, Fedora, Mandriva and Mageia whereas some people complain about freezes
> under Ubuntu. I'm glad to see JOGL working on Meego but which JVM do you
> use?
>

The default, OpenJDK6 w/ IcedTead-Web Plugin 1.1.3-1ubuntu1.1

(You can find this information in the screenshot - info Applet)

It's the std. Ubuntu 11.10 installation for Linux ARMv7
plus the omap4 extras.

~Sven

signature.asc (910 bytes) Download Attachment

Re: Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

2012-02-28T01:12:16Z

Hi

As far as I know, OpenJDK works better on some distros especially with applets for unknown reasons. I have never had any problem under Cent OS, Red Hat, Fedora, Mandriva and Mageia whereas some people complain about freezes under Ubuntu. I'm glad to see JOGL working on Meego but which JVM do you use?

Julien Gouesse
http://tuer.sourceforge.net
http://gouessej.wordpress.com

Re: Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

2012-02-27T18:10:31Z

The screenshot (from the blog):
<http://jausoft.com/blog/wp-content/uploads/2012/02/jogamp-jogl-armv7-omap4.png>

Jogl/JogAmp RC6 Beta / Linux Armv7 Builds

2012-02-27T18:01:26Z

http://jausoft.com/blog/2012/02/27/jogamp-rc6-beta-linux-armv7-builds/

Besides adding proper Mac OS X support (10.5.8 - 10.7.*, incl. OpenJDK7),
OpenGL 4.2 and latest EGL, ES1 and ES2 extension updates and lot's of stabilization's,
Xerxes Rånby <http://labb.zafena.se/?p=532> and myself worked on a proper Linux ARMv7 support.
Both were able to test on Omap4 (Pandaboard ES), Tegra2 (AC100), where Xerxes also tested on other machines, eg. Nokia N9 MeeGo.

Even though GlueGen and JOGL in general support EGL and ES1/ES2 since 2008 incl. the GL profile selection,
we figured we need better support for multiple GL implementations on one platform, Mesa3D software and the hardware EGL/ES ones.
Without tweaking your default configuration, JOGL chooses the right implementation for the desired profile,
e.g. hardware accelerate GLES2 for the desired common GL2ES2 profile on your mobile device, even though Mesa is installed.

Besides tiny big fixes and workarounds the biggest amount of work was to attach the Linux ARMv7 job to Jenkins.
We use a cross-compile and cross-test environment, where the build host cross-compiles and makes the Pandaboard ES
fetch the artifacts via rsync and execute the tests. Later the build host pulls the results and forwards them to the Jenkins master.

All JogAmp modules are now build for Linux-Armv7,
a test release is made available here: <http://jogamp.org/deployment/jogamp-test/>.
You may like to try the test Applets: <http://jogamp.org/deployment/jogamp-test/jogl-test-applets.html>.
Note: This week RC6 will be released under the usual location and the above test URL will cease to exist.

I dared to test browser support via OpenJDK and the IcedTea Plugin,
and for some reason .. it just works :)

Cheers, Sven

signature.asc (910 bytes) Download Attachment

Re: JOGL upgrade fails

2012-02-12T15:53:42Z

On 02/13/2012 12:50 AM, clevengr [via jogamp] wrote:
>
>
> One more thing: am I correct in assuming that the JAR cacheing mechanism also
> applies to Linux and OS-X, so that it's no longer necessary to put the .so's
> in the LD_LIBRARY_PATH?

yes, none is required or advocated anymore.

also - next version won't have platform archives anymore,
use the *all-platform* 7z archive.

you may also put the 'official' release URL into your 'handout'
jogamp-current .. -next .. etc, when you update it.

~Sven

>
> Thanks.

signature.asc (910 bytes) Download Attachment

Re: JOGL upgrade fails

2012-02-12T15:50:11Z

One more thing: am I correct in assuming that the JAR cacheing mechanism also applies to Linux and OS-X, so that it's no longer necessary to put the .so's in the LD_LIBRARY_PATH?

Thanks.

Re: JOGL upgrade fails

2012-02-12T13:48:44Z

Well THAT explains a lot :) Thanks!

I agree this is a much better scheme. What is frustrating for me (and I suspect a lot of other users) is how hard it is to understand and keep up with the changes in the system(s). (For example, the JOGL "User's Guide" hasn't been updated since the JSR 1.1 version).

I do know how hard it is to keep things updated, and I have great sympathy for the issues involved in generating documentation on volunteer projects (I have personal experience in that in another arena).
I greatly appreciate all the work the people in the JogAmp community do, and how fast responses are generated.

In case it is useful to anyone, here is my attempt to document at least a little bit of the process of using JOGL:
ftp://gaia.ecs.csus.edu/clevengr/165/handouts/JOGLv2.0Installation.pdf
(Comments and/or corrections are most welcome..)

Thanks for the help.

Re: JOGL upgrade fails

2012-02-12T13:42:59Z

On 02/12/2012 10:26 PM, Wade Walker [via jogamp] wrote:
>
>
>
> One possible disadvantage of this system is that when you upgrade your JOGL
> JARs, the DLL caching system has to be smart enough to overwrite the old
> DLLs (but it can't just always overwrite them, since this would slow down
> startup times). There can also be problems finding a directory where the
> user has write permissions, depending on the OS and how the user permissions
> are set up. But once these problems are solved, it's a good system.

We have different levels of cache to consider here.

GlueGen Jar Cache:

The new cache with GlueGen I have added always starts from scratch
with a new JVM / ClassLoader, this is a requirement to native libraries
and it's classloader. We have a JVM level folder and within a classloader one.

The caches will be removed at startup when no lock is hold on it.

+++

Java (RT) Jar Cache (Network .. etc):

In case the base URL of the source of eg jogl.all.jar
is a network resource like http (Applets etc),
Java itself caches it and usually allows fast access
when the remote source has not changed.
However .. I have experienced a bug here (OS X I guess),
where the network cache returned an old JAR file.

+++

In conclusion I think our Jar Cache has no big side effects
or downsides. The same semantics was used within the AppletLauncher
and it worked quite well for a long time.

Wade and myself were able to fix a few 'odds' already.
Since it is already the default and 'in production' for a few month,
we haven't heard about complains so far.

~Sven

signature.asc (910 bytes) Download Attachment