MusicMan3001

Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • in reply to: FFGL downloads? #59477
    MusicMan3001
    Participant

    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.

    in reply to: FFGL downloads? #59467
    MusicMan3001
    Participant

    Thanks. That build looks like it is from several years ago. Is it considered up-to-date (with the latest Syphon Framework)?

    in reply to: Grey Screen of Death #58978
    MusicMan3001
    Participant

    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.

    in reply to: Grey Screen of Death #58971
    MusicMan3001
    Participant

    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?

    in reply to: Grey Screen of Death #58968
    MusicMan3001
    Participant

    Ok, actually I don’t think that’s the problem. But I think this is:
    http://www.cocoabuilder.com/archive/cocoa/107699-nsopenglview-from-second-nsthread.html

    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.

    in reply to: Grey Screen of Death #58967
    MusicMan3001
    Participant

    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?

    in reply to: Client loses connection when Server changes context #31796
    MusicMan3001
    Participant

    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 reply to: Grey Screen of Death #29285
    MusicMan3001
    Participant

    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:
    https://github.com/Syphon/Syphon-Framework/issues/2

    in reply to: Grey Screen of Death #17639
    MusicMan3001
    Participant

    Sorry, I should have given more detail.  Basically I am doing this:

    SyphonImage *myFrame = [myClient newFrameImageForContext:myContext];
    if (myFrame)
    {
    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.

    in reply to: Grey Screen of Death #17637
    MusicMan3001
    Participant

    Commenting out this line in my code prevents the problem:

    glBindTexture(GL_TEXTURE_RECTANGLE_ARB, myTexName);

    Strange, right?  Any ideas?

    Also, is there some reason why you don’t just support GL_TEXTURE_2D?

     

    in reply to: Grey Screen of Death #17629
    MusicMan3001
    Participant

    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.

Viewing 11 posts - 1 through 11 (of 11 total)