• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: OpenGL context sharing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OpenGL context sharing


  • Subject: Re: OpenGL context sharing
  • From: Alexander Spohr <email@hidden>
  • Date: Thu, 26 Mar 2009 22:33:11 +0100

Sounds like your context is not set.
How do you call the „drawing code“ in B?

Possible solution:
Make a subclass of NSOpenGLView that overrides drawRect: in A
Give it a delegate and make some instance from B the delegate.
Trigger [NSOpenGLViewSubclass display]
NSOpenGLViewSubclass should then tell the delegate in B to draw.
Done.

	atze

ps. set NSOpenGLViewSubclass in the nib to be your view :)


Am 26.03.2009 um 18:07 schrieb Clemens Arth:

Hi,

I got a question to a rather weird problem I came across. We are developing an entire software suite in a set of shared libraries which are linked together with some type of Bootloader to an application. One library contains stuff related to IO, one contains rendering stuff and so on. I have to note here that this works well on Linux and Windows, and now I've tried to port that to OSX. I've tried to do achieve the same behaviour as on Linux and on Windows as follows:

In the IO library I created an interface for opening a nib file called WinControl which contains the outlets. The nib file itself only contains a NSOpenGLView which is embedded in an NSWindow. In principle this works quite well if I set the File Owner of the nib file to be of the class WinControl and do something like

/* snip */
WinControl * control = [[WinControl alloc] init];
[NSBundle loadNibNamed:@"MyNibFile" owner:control];
/* snip */

Note that this loading-of-nibs stuff is all contained in library A, and it seems that all drawing code also contained in library A works as expected.

Now, in our case library B contains the real important rendering stuff, also including code to compile shaders. The real problem I have here is:

If I create an application linking to A and B, the code in library B is not able to make use of the OpenGL context which is obviously created through library A (simply by loading a nib file with an embedded NSOpenGLView). After trying a lot of different things I'm pretty sure that this has to do with the question of "owning" the context. If I call drawing code contained in A from a function contained in B everything works, but if I include the drawing code directly in B it does not work (crashing with EXC_BAD_ACCESS).

Does someone have an idea what I can do about that? I'm a more-or- less beginner in Cocoa programming, and I'd really appreciate if someone could explain to me how to circumvent this problem without changing the overall structure of the software suite (i.e. the modularization into separate libraries for different tasks).

Regards
Clemens

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: OpenGL context sharing
      • From: Clemens Arth <email@hidden>
References: 
 >OpenGL context sharing (From: Clemens Arth <email@hidden>)

  • Prev by Date: Re: Confounding crash, not much to go on except a stack trace
  • Next by Date: Re: CoreLocation
  • Previous by thread: OpenGL context sharing
  • Next by thread: Re: OpenGL context sharing
  • Index(es):
    • Date
    • Thread