June 2010 - Pro-apps-dev - lists.apple.com

Re: PBuffer_Create and compatible pixel format
by Steve Christensen 28 Jun '10

28 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Jun 28, 2010, at 9:08 AM, Darrin Cardani wrote: On Jun 24, 2010, at 7:30 PM, Steve Christensen wrote: CGLError error = kCGLNoError; Thanks for helping to dig up more detailed information. steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I'm not sure if it's better to ask here or on the OpenGL list, so please point me there if this is off-topic. I'm using PBuffer_Create and friends in a plugin (included in EffectHelpers.m in the FxPlug samples). It works fine except on one of our test computers that contains multiple graphics cards and displays. For that case it fails with the stock code when calling CGLCreateContext. I've ended up modifying it as follows and now works on all of our computers. pbuffer->pixelFormat = CGLGetPixelFormat(sharedContext); if (pbuffer->pixelFormat == NULL) { // do the stock pixel format setup here //... error = CGLChoosePixelFormat(pixelFormatAttributes, &pbuffer- >pixelFormat, &numPixelFormats); } if (error == kCGLNoError) { error = CGLCreateContext(pbuffer->pixelFormat, sharedContext, &pbuffer->pbufferContext); //... } The problem is that I need to add a couple of attributes to the pixel format. If I were to use the stock code, it'd be no problem: just add it to the list. However on our problem computer, the shared context's pixel format has two virtual screens, so I'm unsure how to get ahold of all of the attributes, add the new ones, and then create a new pixel format. Is this possible or am I going off in the wrong direction? Steve, I forwarded this on to someone else on our team who was more intimately familiar with this aspect of OpenGL, and here's what he said: In general, what he's trying to do is tough to get right. I ran into something similar (and I'm not convinced I got it right either). I'm only guessing about what he's doing from his description, but it sounds like he wants to -- get the CGLPixelFormatObj from an existing CGLContextObj -- use CGLDescribePixelFormat to get various attributes from an existing CGLPixelFormatObj -- tweak/add to those attributes -- then build a new CGLPixelFormatObj with the tweaked attributes -- which he then uses to try to create a new CGLContextObj that shares with the original CGLContextObj Two gotchas I ran into: 1) when there are multiple GPUs/virtual screens installed, the renderer ID that comes back from CGLDescribePixelFormat is essentially useless, so he should not specify this attribute (you never really need to anyway); and 2) he has to specify the kCGLPFAAllowOfflineRenderers attribute in the pixel format (if he's doing the above, he's probably already doing this because it would be one of the attributes that comes back from CGLDescribePixelFormat from our context, but just to be sure). Part of what makes this tough to get right is that there could be additional attributes that get added in the future that might be important that he wouldn't know to copy. Also, some attributes can't be tweaked like this; if he's changing pixel format (e.g., float vs. int) or asking for different buffers, it just may not be possible. Part of the feedback I got from one of the OpenGL engineers is that maybe rethinking the strategy might be more effective (e.g., using an FBO instead of a PBuffer). Yes, he's right about what we're trying to do. For the simple case that PBuffer_Create supports, I'd just add the attributes to the array and be done with it. The problem we ran into was when we were runnning on a computer with multiple virtual screens, when the context creation failed. My original question was prompted because I ran into a roadblock where I couldn't figure out how to set up the pixel format attributes to specify multiple virtual screens; you can read them back after the fact, but I couldn't figure out how to set it up in the first place... This email sent to site_archiver(a)lists.apple.com

1 0

Re: PBuffer_Create and compatible pixel format
by Darrin Cardani 28 Jun '10

28 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Jun 24, 2010, at 7:30 PM, Steve Christensen wrote: CGLError error = kCGLNoError; Darrin -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I'm not sure if it's better to ask here or on the OpenGL list, so please point me there if this is off-topic. I'm using PBuffer_Create and friends in a plugin (included in EffectHelpers.m in the FxPlug samples). It works fine except on one of our test computers that contains multiple graphics cards and displays. For that case it fails with the stock code when calling CGLCreateContext. I've ended up modifying it as follows and now works on all of our computers. pbuffer->pixelFormat = CGLGetPixelFormat(sharedContext); if (pbuffer->pixelFormat == NULL) { // do the stock pixel format setup here //... error = CGLChoosePixelFormat(pixelFormatAttributes, &pbuffer- >pixelFormat, &numPixelFormats); } if (error == kCGLNoError) { error = CGLCreateContext(pbuffer->pixelFormat, sharedContext, &pbuffer->pbufferContext); //... } The problem is that I need to add a couple of attributes to the pixel format. If I were to use the stock code, it'd be no problem: just add it to the list. However on our problem computer, the shared context's pixel format has two virtual screens, so I'm unsure how to get ahold of all of the attributes, add the new ones, and then create a new pixel format. Is this possible or am I going off in the wrong direction? Steve, I forwarded this on to someone else on our team who was more intimately familiar with this aspect of OpenGL, and here's what he said: In general, what he's trying to do is tough to get right. I ran into something similar (and I'm not convinced I got it right either). I'm only guessing about what he's doing from his description, but it sounds like he wants to -- get the CGLPixelFormatObj from an existing CGLContextObj -- use CGLDescribePixelFormat to get various attributes from an existing CGLPixelFormatObj -- tweak/add to those attributes -- then build a new CGLPixelFormatObj with the tweaked attributes -- which he then uses to try to create a new CGLContextObj that shares with the original CGLContextObj Two gotchas I ran into: 1) when there are multiple GPUs/virtual screens installed, the renderer ID that comes back from CGLDescribePixelFormat is essentially useless, so he should not specify this attribute (you never really need to anyway); and 2) he has to specify the kCGLPFAAllowOfflineRenderers attribute in the pixel format (if he's doing the above, he's probably already doing this because it would be one of the attributes that comes back from CGLDescribePixelFormat from our context, but just to be sure). Part of what makes this tough to get right is that there could be additional attributes that get added in the future that might be important that he wouldn't know to copy. Also, some attributes can't be tweaked like this; if he's changing pixel format (e.g., float vs. int) or asking for different buffers, it just may not be possible. Part of the feedback I got from one of the OpenGL engineers is that maybe rethinking the strategy might be more effective (e.g., using an FBO instead of a PBuffer). This email sent to site_archiver(a)lists.apple.com

1 0

PBuffer_Create and compatible pixel format
by Steve Christensen 25 Jun '10

25 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com CGLError error = kCGLNoError; steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I'm not sure if it's better to ask here or on the OpenGL list, so please point me there if this is off-topic. I'm using PBuffer_Create and friends in a plugin (included in EffectHelpers.m in the FxPlug samples). It works fine except on one of our test computers that contains multiple graphics cards and displays. For that case it fails with the stock code when calling CGLCreateContext. I've ended up modifying it as follows and now works on all of our computers. pbuffer->pixelFormat = CGLGetPixelFormat(sharedContext); if (pbuffer->pixelFormat == NULL) { // do the stock pixel format setup here //... error = CGLChoosePixelFormat(pixelFormatAttributes, &pbuffer- >pixelFormat, &numPixelFormats); } if (error == kCGLNoError) { error = CGLCreateContext(pbuffer->pixelFormat, sharedContext, &pbuffer->pbufferContext); //... } The problem is that I need to add a couple of attributes to the pixel format. If I were to use the stock code, it'd be no problem: just add it to the list. However on our problem computer, the shared context's pixel format has two virtual screens, so I'm unsure how to get ahold of all of the attributes, add the new ones, and then create a new pixel format. Is this possible or am I going off in the wrong direction? This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP: dragging image from bin to NSImageView?
by Darrin Cardani 21 Jun '10

21 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Jun 18, 2010, at 6:59 PM, Steve Christensen wrote: Darrin -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I did try a version with the image reference parameter but it didn't look like the plugin was being notified (-parameterChanged:) after an image was dropped onto it (FCP 6.x), which we kinda need to know. That sounds really familiar. I'm thinking that was a bug that was fixed in FCP 7, though I'm not positive. I can see if I can dig up the bug later today, but if you have FCP 7, try it out. This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP: dragging image from bin to NSImageView?
by Steve Christensen 19 Jun '10

19 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Paul, Thanks for the info... steve On Jun 18, 2010, at 3:52 PM, Paul Schneider wrote: Hi Steve, - Paul On Jun 18, 2010, at 3:12 PM, Steve Christensen wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Hmmm... too bad. We're going the NSImageView route because we're modifying what gets displayed in addition to wanting to be able to track drops on the view. We were hoping to be able to add bins into the mix so that we could cover all image sources, but it sounds like that's not going to happen. I did try a version with the image reference parameter but it didn't look like the plugin was being notified (-parameterChanged:) after an image was dropped onto it (FCP 6.x), which we kinda need to know. The data that FCP puts on the pasteboard isn't a reference to a file on disk; it's an internal representation of the FCP objects in the bin. You'll have to register for custom drag types. I don't know off the top of my head what we put on the pasteboard. It would be nice if it were XML, because then your plugin could read it. But I suspect it's a private binary format. I'm pretty sure you'll have to use FxPlug's standard image reference parameters to get a reference to something in an FCP bin. My plugin has a custom parameter that includes a NSImageView configured for editing (drag&drop). If I drag an image from the desktop, the image is accepted and appears in the view, as expected. If I first drag the same image into a bin then drag from the bin onto the image view, the panel containing all the plugin's parameters highlights (darkened border) but the image view doesn't accept the image. Do I need to be aware of some other pasteboard types beyond what NSImageView knows about; is FCP just allowing bin image drags to the built-in image parameter; or is something else going on? steve This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP: dragging image from bin to NSImageView?
by Paul Schneider 18 Jun '10

18 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Steve, The data that FCP puts on the pasteboard isn't a reference to a file on disk; it's an internal representation of the FCP objects in the bin. You'll have to register for custom drag types. I don't know off the top of my head what we put on the pasteboard. It would be nice if it were XML, because then your plugin could read it. But I suspect it's a private binary format. I'm pretty sure you'll have to use FxPlug's standard image reference parameters to get a reference to something in an FCP bin. - Paul On Jun 18, 2010, at 3:12 PM, Steve Christensen wrote: > My plugin has a custom parameter that includes a NSImageView configured for editing (drag&drop). If I drag an image from the desktop, the image is accepted and appears in the view, as expected. > > If I first drag the same image into a bin then drag from the bin onto the image view, the panel containing all the plugin's parameters highlights (darkened border) but the image view doesn't accept the image. > > Do I need to be aware of some other pasteboard types beyond what NSImageView knows about; is FCP just allowing bin image drags to the built-in image parameter; or is something else going on? > > steve > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com > > This email sent to pschneider(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

FCP: dragging image from bin to NSImageView?
by Steve Christensen 18 Jun '10

18 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… My plugin has a custom parameter that includes a NSImageView configured for editing (drag&drop). If I drag an image from the desktop, the image is accepted and appears in the view, as expected. If I first drag the same image into a bin then drag from the bin onto the image view, the panel containing all the plugin's parameters highlights (darkened border) but the image view doesn't accept the image. Do I need to be aware of some other pasteboard types beyond what NSImageView knows about; is FCP just allowing bin image drags to the built-in image parameter; or is something else going on? This email sent to site_archiver(a)lists.apple.com

1 0

Re: FxPlug Loading Questions
by Bob Currier 13 Jun '10

13 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Pete, Paul: Just wanted to say thanks. Everything is working fine now. -- Bob _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP preferences/paths
by Tim Jones 11 Jun '10

11 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP preferences/paths
by Darrin Cardani 11 Jun '10

11 Jun '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0