Syphon JNI Binding

[sbook]

Hi all,

I’ve started work on a JNI binding for Syphon for which @vade has graciously offered Objective-C assistance. As promised earlier, here is a small prototype of a way I think this can go:

https://students.bxmc.poly.edu/svn/betaville/branches/JSyphon/

My original plan was to wrap up the entire framework into JNI but after further consideration, I don’t think this is necessary. A simplified access mechanism to the client and server side should make it fairly easy to allow Syphon to work with both LWJGL and JOGL (as well as associated graphics engines using the aforementioned).

What I’m envisioning is a client hook and a server hook that allows you to either grab the texture from a specified server or to publish your texture acting as a server. In this way we should be able to keep the binding fairly clean with most of the Syphon work being done in the native implementation.

Thoughts?

P.S: In putting the few sources on a repository, I feel it necessary to put in some kind of license, so any Java or native header & implementation files are hereby released under Simplified BSD, same as Syphon. (The test files I’ve posted there are GPL’d and currently useless anyway 😉 )

[vade]

Looking at this quickly, you’d probably want to just make wrapper objects for SyphonClient, SyphonServer and SyphonServerDirectory, rather than having one SyphonHookObject. It delineates responsibility and makes it clear what object performs what role, no?

[sbook]

That was part of my dilemma, while it keeps things closer to the way things are done natively I wasn’t sure if they’d ever be needed once the initial implementation was done. Perhaps said more succinctly, is it necessary for an end user to know what object performs what role? IMHO, someone is going to want to get a list of servers and get the associated asset.

In any event, we should probably at least start as straightforward as possible, the Hook object can always be revisited later. So only those three classes? I’ll push the headers and what I can of the implementation tonight or in the morning.

[vade]

Part of whats going to happen, if you get this working, is that it will be the basis for other JNI implementations, like Processing etc. Keep it simple stupid, so its easy to follow in all codebases.

[skawtus]

Hi sbook & vade,

I was working on this for a few days last week as well with limited success…

From the jni bridge, finding and connecting to syphon servers seemed to work consistently, though calls to the syphon library from a jni function always produced loads of “__NSAutoreleaseNoPool()” errors.

In any case, I was getting garbled data on the client read and could not figure it out, so instead of beating my head on this too badly, I wish you success on making this work soon!

[bangnoise]

skawtus – calls to Cocoa-land need an autorelease pool set up around them –

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// Cocoa calls here
[pool drain];

sbook – as vade says, breaking the functionality down to something similar to the Cocoa API (the three distinct objects) seems the simplest way to do things – but you don’t need to exactly mirror the API where it doesn’t make sense – for instance it may not be feasible to support new frame handlers. If you get one way of serving frames and one way of drawing them from clients working, then perhaps someone else will flesh that out if they need the other features…

Great that there is a start at this – thanks!

[vade]

skawtus : do you have your JNI work in a repo? I’d be curious to see the garbage you got. It sounds like the Syphon was not seeing a valid GL context, thus getting garbage texture IDs, or FBO content?

[skawtus]

bangnoise – Thanks for the tip! I still get them errors, so I may be doing something wrong still… all alloc’s need to be also specified as ‘autorelease’ no?

vade – Here is the link to code repo I was using for the processing library. Essentially, I never got past hacking the sdk’s client example to work with jni because of the above mentioned errors… I am having trouble reproducing the garbage data mentioned before, as the client code doesn’t seem to be recieving frames. Not sure which iteration of the code was receiving frames at this point… (I have some beers if I get annoyed at code…)
This is folder for the xcode project…
https://code.google.com/p/syphonprocess/source/browse/#hg/lib/Humble
…and the jni link
http://code.google.com/p/syphonprocess/source/browse/lib/Humble/src/Humblejnilib.m

sbook – Progress? I hope you are making strides actually. In any case, I would love to work together with you on this…

My approach was to use Xcode to build the jni bridge, and eclipse to build the processing library… I could not really get eclipse to compile/link jni/syphon/processing libs, all at the same time… ergo I chose the multi-ide compilation build chain.

I ultimately just want a packaged processing library, though, I suppose, I can make do using oF or cinder for this next month’s fun. I am too busy and lazy to spend months making jni talk cocoa… maybe we can figure this out soonish?

[vade]

Hi!

scad = [[[SimpleClientAppDelegate alloc] init] autorelease];

You do not want to do this. This is releasing (deallocing) you object the next time the auto release pool is drained. You are telling the memory management system “mark this as being able to go away at any time in the future, at your leisure”. Thats not what you want. Having the auto-release pools how you have them is correct, that should be all you need for proper memory management in cocoa, assuming your objects are properly retained/released within the code.

Those “extra” auto-releases are going to remove objects out from under you without you knowing when, which is bad!

edit: this is to say, an auto-release pool facilitates the ‘auto release’ mechanism to work, so autorelease messages will *release* objects (auto release pools also handle other things, but just clarifying that you want to have the *pools* in place, but do not want to *auto-release* objects you want to stick around :).

[sbook]

sbook – Progress? I hope you are making strides actually. In any case, I would love to work together with you on this…

Unfortunately, not much considering that I seem to be trapped in a similar place as you concerning JNI<->Cocoa. As I’ve been coming at it more from the ported API perspective that vade mentioned, dealing with objects has been some fun. With the next chunk of time I get over the weekend I was planning on rethinking the thing a bit so that the Java code becomes more about holding pointers to Syphon objects.. Its quite a bit different than my current JNI know-how involving LWJGL.

Concerning linking the native libraries, I notice that you used System.loadLibrary().. For what its worth, I’ve had a better success rate using System.load and giving it a path (not sure if that’s one of your linking issues, but I thought it worth mentioning).

I want to do some playing with your implementation as well over the weekend though, as you’re significantly further on the native side than I’ve gotten..

[bangnoise]

Any progress? If you’re struggling on the C/Objective-C side of things, we can pitch in with that… if you can come up with everything else (Xcode project to build library with empty functions for us to fill, whatever is needed to build the Eclipse part, example Processing sketch) we can fill in the Cocoa blanks…

[vade]

A very very early proof of concept Syphon <-> LWJGL JNI bridge is in the Syphon Implementations, under “JSyphon”. Heavy work in progress, but stay tuned.

[andres]

Hi, I’m working on the JSyphon-based library for Processing.

I just managed to get everything compiled, but having some trouble to load the native libraries.

Actually, I’m not that experienced with OSX development, so please bear with me for a while 🙂

As far as I understand from a first examination of the code, libJSyphon.dylib calls the underlying Syphon functions through JNI. Looking at how the dependencies are embedded into this dylib, the low-level Syphon library is just called Syphon and should be located in @loader_path/Syphon.framework/Versions/A/Syphon

This means that if libJSyphon.dylib is placed in /Users/andres/sketchbook/libraries/Syphon/library, then the Syphon library should be in /Users/andres/sketchbook/libraries/Syphon/library/Syphon.framework/Versions/A.

I tried this, but when the Processing library tries to call the initWithName() method, I get:

Exception in thread “Animation Thread” java.lang.UnsatisfiedLinkError: codeanticode.syphon.JSyphonServer.initWithName(Ljava/lang/String;)V
at codeanticode.syphon.JSyphonServer.initWithName(Native Method)

Any comments?

[vade]

Are you sure you are able to properly load with System.loadLibrary(“JSyphon”) the libJSyphon.dylib ? What are the Java class paths you have – do they match the path you quote above?

The ServerTest.java LWJGL test app has a print statement to help debug the library load issues, and I believe Eclipse manually adds the library paths when you edit the Project GUI (The other JSyphon dev, Skye Book helped me on that point, so I am admittedly a bit out of my element here).

Perhaps Eclipse is doing something overly intelligent, or coincidental, because of how it has paths set up? Perhaps @loader_path matches ones of the Java library paths (so that both @loader_path and Eclipse look in the same path – and perhaps Processing for some reason, has @loader_path pointing somewhere else – although, @loader_path realllyyy ought to be relative to the libJSyphon.dylib).

Isnt this fun?

Are you certain the libJSyphon.dylib is being loaded? Try editing the JSyphonServer class and attempt to log in the constructor, and see if it that works?

Im also new to JNI development, so bare with me 🙂

[vade]

Edit: Oh, wait a second. Are you putting the Syphon.framework in to a set of folders called /libraries/Syphon.framework/Versions/A

Basically, the libJSyphon.dylib needs to be at the same level as the compiled out (from XCode) Syphon.framework, so you have 2 files like so :

Did you get the Syphon-Framework SVN project checked out and compiled, so you have the latest Syphon.framework, and you can if you have the paths set up properly, link the JSyphon XCode project to automatically build the Syphon-Framework project by enusing the paths are set up, so that your top level Syphon-Implementations check out is at the same folder as the top level Syphon-Framework check out, like so:

[andres]

The ServerJava example works as expected in my OSX 10.6.7 system, using the latest JSyphon code pulled from the trunk.

I followed the file structure that you indicate in the screenshots, namely, libJSyphon.dylib and Syphon.framework at the same level.

I made the Processing sketch that attempts to load Syphon into an Eclipse project:

http://interfaze.info/files/syphon/SyphonHello.zip

When running the project as Java application, you can see that the JSyphon object is created, and the library path contains the required information to load Syphon, but then the error java.lang.UnsatisfiedLinkError shows up.

[vade]

You Syphon framework does not contain links, but multiple versions of the binary.

Yours:

Proper framework

This is the Processing library? Do I just make a new sketch and place these in the Libraries folder for Processing, and attempt to import it ?

[vade]

I think I see part of the issue.

1) I had a bug with the XCode script, that accidentally flattened out the Syphon.framework and resolved aliases (a bad flag)

2) Make sure you compile libJSyphon.dylib as release, so you get a universal library

3) I need to follow my own advice and remove PPC architectures from libJSyphon XCode build process.

Im in the process of updating SVN to fix these issues. Now that the build is semi-worked out, I do think its loading the dylib. Im not quite sure where to go from here, but i’ve found a few threads regarding this on Apples dev site (one specifically mentioning processing). Need to do some more debugging.

[andres]

Thanks for the follow-up. I run again the test application with the latest revisions from the svn and still get the unsatisfied link error. I will keep an eye on the coming updates to JSyphon, and will let you know if in the meantime I find anything else relevant to this issue.

[vade]

I have it working.

I had to remove the namespace codeanticode, and re-compile the class files which I exported as a jar from eclipse.

I then placed that jsyphon.jar (containing only the Syphon stuff, no test, or utils since they are unused for now) in to

/MySketch/libraries/jsyphon/library/:

[Author]

Posts