Home › Forums › Syphon › Syphon Development – Developer › Syphon JNI Binding
- This topic has 40 replies, 5 voices, and was last updated 9 years, 8 months ago by bangnoise.
-
AuthorPosts
-
April 14, 2011 at 5:33 pm #5110vadeKeymaster
Here is a screenshot. I need to get Processing talking to native OpenGL, so I can get Raw texture IDs.
I will upload this to SVN later this evening, maybe tomorrow, as I have some pressing engagements shortly, however this is great news 🙂
April 14, 2011 at 6:53 pm #5111andresParticipantExcellent! I’ll make a new library package that incorporates the opengl integration once you push all the latest changes to the trunk.
April 14, 2011 at 8:20 pm #5112andresParticipantBTW, I made some modifications to the OPENGL2 renderer so it is now easy to get the GL parameters from the textures encapsulated by a PImage, but this will work only on releases after 0195.
April 15, 2011 at 4:06 pm #5113andresParticipantOk, I got everything running!
The Processing library is here:
http://interfaze.info/files/syphon/Syphon-0.0.1.zip
However, it only works with the latest revision from Processing trunk 🙂
I also would like to contribute a small ant build file that generates the jsyphon jar file, discarding the test files. You can include it in the syphon repo if you want.
Cheers!
April 15, 2011 at 4:10 pm #5114andresParticipantApril 15, 2011 at 4:22 pm #5115vadeKeymasterOh awesome. So you can send a PImage now, and the Syphon java class will handle sending that to Syphon as a texture? Very cool. I got it working in 1.2.1 using the PGraphics object to get a GL handle and manually read a texture from the screen, like so:
// OpenGL import javax.media.opengl.*; import processing.opengl.*; // Syphon import jsyphon.*; PGraphicsOpenGL pgl; float a; JSyphonServer mySyphon; void setup() { size(800, 600, OPENGL); mySyphon = new JSyphonServer(); mySyphon.test(); mySyphon.initWithName("Syphon - Processing"); // get an OpenGL handle pgl = (PGraphicsOpenGL) g; // add shutdown and close handlers /* Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { public void run() { ohGodStop(); } })); */ } void draw() { background(255); GL gl = pgl.beginGL(); gl.glColor4f(0.7, 0.7, 0.7, 0.8); gl.glTranslatef(width/2, height/2, 0); gl.glRotatef(a, 1, 0, 0); gl.glRotatef(a*2, 0, 1, 0); gl.glRectf(-200, -200, 200, 200); gl.glRotatef(90, 1, 0, 0); gl.glRectf(-200, -200, 200, 200); // copy to texture, to send to Syphon. int[] texID = new int[1]; gl.glEnable(gl.GL_TEXTURE_RECTANGLE_EXT); gl.glGenTextures(1, texID, 0); gl.glBindTexture(gl.GL_TEXTURE_RECTANGLE_EXT, texID[0]); gl.glTexImage2D(gl.GL_TEXTURE_RECTANGLE_EXT, 0, gl.GL_RGBA8, width, height, 0, gl.GL_RGBA, gl.GL_UNSIGNED_BYTE, null); gl.glCopyTexSubImage2D(gl.GL_TEXTURE_RECTANGLE_EXT, 0,0, 0, 0, 0, width, height); mySyphon.publishFrameTexture(texID[0], gl.GL_TEXTURE_RECTANGLE_EXT, 0, 0, width, height, width, height, false); gl.glDeleteTextures(1, texID, 0); pgl.endGL(); a += 0.5; }
April 15, 2011 at 4:25 pm #5116vadeKeymasterOh, and thanks for the zip too, btw. How do you suggest we roll this into the SVN, organizationally speaking? Do you want SVN access as a committer so you can help handle the processing library and Java side, if thats would be something of interest?
April 15, 2011 at 4:29 pm #5117vadeKeymasterOh, one last thing, the JSyphon java library will eventually have objects for clients and servers, so I would suggest that the Processing library be more specific, so creating a SyphonServer object for sending, and a SyphonClient object for receiving, etc, would be helpful for keeping the API more readable and conceptually sound. We can totally hammer this out though once we get that functionality actually working 🙂
April 15, 2011 at 5:23 pm #5118andresParticipantyes, you can add me as a committer, I think is good idea. Perhaps the Processing library could be just hosted in the syphon repo?
I also agree about making the Processing library more specific. We will figure out the details of the API as we move along. So far, things look very good. Thanks for all your work!
April 15, 2011 at 5:33 pm #5119vadeKeymasterThank you andres for your help and putting the library together.
I’ve added you as a committer in the http://code.google.com/p/syphon-implementations/
I’ve made a top level “Processing” folder along side the other implementations, so you can put the library there. Add a readme if you want and make sure to put yourself in the credits!
Happy hacking, and thanks again! Let me know if you end up needed to mess with the JSyphon JNI shit, just so we can communicate. You can ping me at v a d e [at] v a d e [dot] i n f o if you need to.
April 18, 2011 at 4:00 am #5120andresParticipantquick question: is the client API in jsyphon already functional?
April 18, 2011 at 4:05 am #5121bangnoiseKeymasterJust looking at the source, it like it does everything apart from emitting images… so not very.
April 18, 2011 at 4:18 am #5122bangnoiseKeymasterI’ve added an issue with a JSyphon TODO list. andres, I think you have more JNI experience than any of us if you’re interested in any of these…
http://code.google.com/p/syphon-implementations/issues/detail?id=8
April 18, 2011 at 7:21 am #5123vadeKeymasterSorry guys, I was away the weekend. I will try and get to it today. I am thinking it may make sense to do without the SyphonImage, and simply have latestFrameImage return a texture ID which can be bound. The additional complexity of emmiting a jobject (the JNI’d version of the Syphon Image) that is temporary, seems kind of of limited use.
Thoughts?
April 18, 2011 at 12:33 pm #5124bangnoiseKeymasterWe need to encapsulate the SyphonImage which owns the texture, otherwise you’ll end up drawing with an invalid texture ID – the only way to do that without an extra object would be to have “lock” and “unlock” functions in the client which retain the current SyphonImage then release at unlock, but that greatly complicates multi-threaded use.
April 18, 2011 at 11:53 pm #5125andresParticipantJust to understand a little better how the client works, first thing it should do is to retrieve a list with the running servers, right? is this what JSyphonClient.serverDescription() is supposed to return?
April 19, 2011 at 1:28 am #5126bangnoiseKeymasterIn the framework itself, we have a separate object for server discovery, SyphonServerDirectory. Having that handled by a class method of JSyphonClient would be fine though I think.
I imagine JSyphonClient.serverDescription() is intended as an exact match for the framework’s SyphonClient.serverDescription, which returns the dictionary describing the remote server. I’m not sure how we want to handle instantiation of clients in JSyphon though – for OpenFrameworks and Cinder we do it using a server name/app-name string pairs to avoid having to pass the serverDescription NSDictionaries used by the framework around, which might make sense here too..? In that case JSyphonClient.serverDescription() would probably be replaced by serverName() and serverAppName() methods.
July 12, 2011 at 4:38 pm #5127andresParticipantHey guys, I finally managed to return to the Syphon code. After inspecting the simple server/client apps, it seems to me that one missing binding in the JSyphon wrapper is for the SyphonServerDirectory functionality, so the list of available servers can be queried before creating the client. I will start with this, and see if I can add a working getAvailableServers method to JSyphonClient that returns a dictionary of the currently available servers.
July 12, 2011 at 5:57 pm #5128vadeKeymasterIt might make sense to rather than use and pass dictionaries, to use the “SyphonNameBoundClient” which is found in the QC, Jitter and Open Frameworks implementations. The idea is you can pass strings for just a server name, or an app name, and the internals in the name bound client will find the best match.
Thanks *so much* for being interested and lending your talent. We really appreciate it.
July 13, 2011 at 12:26 am #5129andresParticipantok, I see. I will start with this SyphonNameBoundClient class and try to make it work through JNI.
As a side comment, I just thought that another helper class, i.e: SyphonServerList, that uses the same server announce/update mechanism as in SyphonNameBoundClient but just to keep an list of up-to-date servers names, could be useful in order to implement in the Processing library a static method such as String[] SyphonClient.listServers().
-
AuthorPosts
- You must be logged in to reply to this topic.