January 20, 2017 at 2:36 pm #59242
We make Synesthesia. And we have been using the Syphon framework quite a bit. We included it originally so that people can Syphon the output of Synesthesia into another app. But we also ended up using it for our preview window. We’ve got our main OpenGL context running the shaders, and then in the GUI there is a small preview window duplicating the output, like most VJ apps. We actually use Syphon to send the screen content from our main OpenGL context to the small preview window.
First off, I’m wondering if that sounds completely backwards to you. We thought using Syphon to send the output to our preview window (since we’re already running a Syphon server) was a nice, easy solution. Is it that? Or is it an unnecessary/potentially laggy way to do it and we should just use an OpenGL shared context or something of that nature, since it’s all in the same piece of software.
Second: I’m wondering what the best way to report and catch errors is. Are you aware of any times when Syphon could cause a critical error or full crash of the software? We’re trying to make our graphics pipeline more air-tight, so if there are any hardware specific driver errors, like our requested OpenGL context fails be created, the program doesn’t crash, it just reports the error. What are the best practices here?January 22, 2017 at 8:22 am #59243
Using Syphon internally – there’s nothing wrong with doing that, and your per-frame drawing shouldn’t suffer, though the SyphonClient will take a moment to find the server initially. You could use a shared context and the server’s -newFrameImage to get the texture, without the involvement of a SyphonClient.
Syphon shouldn’t cause a crash, ever. The documentation tells you when a method can fail, and what the result of failure will be (eg bindToDrawFrameOfSize: returns a BOOL to indicate success). Check return values and code to deal with the failure value being returned.January 26, 2017 at 8:05 pm #59244
Thanks for the response, bangnoise. Okay, we’ll just handle any errors via return codes if they do arise. And yes, I should have stated we haven’t noticed any errors yet and it is remarkably stable and fast. We use Syphon Recorder quite a bit as well, so thank you and excellent work on that!
As for the internal use, yes I believe we are instantiating a SyphonClient and getting the frame that way, we’ll just use newFrameImage from the server instead.
You must be logged in to reply to this topic.