Forum Replies Created
Ok thanks. Yes, I know that most apps have native support, but a couple of them only have 1 available Syphon output. I was looking for a way to add another.
Thanks. That build looks like it is from several years ago. Is it considered up-to-date (with the latest Syphon Framework)?
All I was saying is that you actually can’t use OpenGL on a secondary thread without locks.
Direct quote from Apple’s documentation: “When you use an NSOpenGLView object with OpenGL calls that are issued from a thread other than the main one, you must set up mutex locking. ”
I’ve gone ahead and implemented these locks in the code I’m working on, so I’ll report back in a bit if I’m still getting crashes.
I understand what you are saying. But I found this link (apologies that it’s a book and was written in 2007): https://books.google.com/books?id=Ryb-k7jrPnIC&pg=PT74&lpg=PT74&dq=what+commands+does+nsopenglview+issue&source=bl&ots=ql64KJbQ2q&sig=fugHPEgKub7RoiT668Fq_w1AIvM&hl=en&sa=X&ei=3MIyVYWPLZbhoASd_YHgBQ&ved=0CDIQ6AEwAw#v=onepage&q=what%20commands%20does%20nsopenglview%20issue&f=false
According to that, and assuming it’s still relevant, the NSOpenGLView class makes implicit OpenGL calls when the window is resized. Thus, from a programming perspective, you can’t control when GL commands will be issued on the main thread. Hence, when using a second thread to do rendering, locking the context is required to ensure the main thread doesn’t interrupt the command stream. And vice versa.
See what I’m saying?
Ok, actually I don’t think that’s the problem. But I think this is:
Apparently all GL functions need to be locked when rendering isn’t in the main thread. NSOpenGLView will call GL functions from the main thread when the window is resized, etc. So not only does the secondary thread have to be locked, but all functions in NSOpenGLView have to be overriden and locked as well.
After a long time without solving this issue (and thus having occasional crashes), I think I finally have some insight. Can you give me your opinion? Hopefully it will help someone else if it’s the right answer.
I’m running Syphon in a plugin, which doesn’t have much access to the host app’s state. So, I never thought twice about using the static function [NSOpenGLContext currentContext]. But now I realize there’s a chance that this function might not return the right context. And if it’s the wrong one, and Syphon tries to use it, things go south pretty quickly.
Am I thinking about it correctly? The proper solution would require I have direct access to the variable which represents the actual context for the window, right?September 3, 2013 at 12:12 pm in reply to: Client loses connection when Server changes context #31796
For my project, I modified the Syphon framework code to add the “replaceCGLContext” method as demonstrated by zakk in SyphonInject, and it seems to work perfectly. The advantage of this (as opposed to the other proposed solution, which is for clients to pick up subsequent identical servers) is that it doesn’t require modification to the client code, so it will work with all existing clients.
In viewing your issue list in response to my other post, it seems that the following issue may be relevant to the problem I have described above:
Sorry, I should have given more detail. Basically I am doing this:
SyphonImage *myFrame = [myClient newFrameImageForContext:myContext];
GLuint myTexName = [myFrame textureName];
NSSize myTexSize = [myFrame textureSize];
… etc. My code is virtually identical to that of the Simple Client.
Keep in mind that this works perfectly fine most of the time. It’s only when the Simple Server is resized that the problem occurs.
I was just thinking that maybe GL_TEXTURE_2D would be less problematic, but maybe not.
Commenting out this line in my code prevents the problem:
Strange, right? Any ideas?
Also, is there some reason why you don’t just support GL_TEXTURE_2D?
No, I can’t recreate it with only the Simple Server and Simple Client. So it’s definitely something I’m doing in my app. Unfortunately my app is too big to share here, and I’m not sure I could whittle it down easily.
I have a MacBook Pro 9,2 with 10.8.2. After the computer restarts, and I view the error report, it definitely seems to be an issue with the graphics driver. Strange. I’m really not understanding why the entire system would reboot instead of just crashing the app. It makes it really difficult to debug!
I’ll have to do some more investigating and get back to you I guess. Thanks.