GLX *and* AGL?

OpenGL
1

I’m a co-author of rgl, a package for R (an open source stats package). Rgl uses OpenGL to display 3D statistical graphics.

On MacOSX, we currently make it a configure option whether to build for AGL or GLX. AGL has the disadvantage that it doesn’t work when R is run as a console application without an event loop; GLX doesn’t work when there’s no X server.

It would be nicer for the user if we could compile for both: detect conditions when AGL would work and use that by default; if not, see if GLX would work; if not, fail.

Is this feasible? In my attempts so far I haven’t been able to get it to build with both AGL and GLX linked in because of duplicate symbols, but I’m relatively inexperienced with this sort of thing. Any help would be appreciated.

2

If you grab the GLUT source code from Apple’s site, there’s a static library you can link to which allows foreground operation of applications without bundles.

3

Can you give more details? I couldn’t find the library.

4

if found this

http://developer.apple.com/referencelibrary/GraphicsImaging/idxOpenGL-date.html

hth

5

and this

http://developer.apple.com/referencelibrary/GraphicsImaging/idxOpenGL-date.html

hth

6

sorry, i meant this

http://developer.apple.com/referencelibrary/GraphicsImaging/index.html

7

Yes, I saw those pages, but I don’t see which entry on them is relevant to my problem (running AGL and GLX from the same application) or the suggested alternative (which I think would allow me to use AGL where I can’t use it now).

8

It sounds like it would be difficult. Even if you could use AGL and GLX side-by-side, you’ll have to deal with the duplicate gl* symbols provided by the two environments.

It’s probably not impossible, but it may not be worth the effort.

9

I recently had to write a carbon library that was linked to command line programs that had to spawn windows and respond to events.

As such I had to handle Carbon Events in a second thread, and run without a bundle.

The library that OneSadCookie is talking about is hard to find.

All you really need is the following:

void osx_AllowForeground()
{
	ProcessSerialNumber psn; /* = { 0, kCurrentProcess }; */
	GetCurrentProcess(&psn);
	TransformProcessType(&psn, kProcessTransformToForegroundApplication);
	SetFrontProcess(&psn);
}

This still assumes you have an event loop, as does the library mentioned above, but it no longer requires a bundle.

You can move the event loop to the second thread like I did. It takes a bit of work, but it comes down to:

Spawn a second thread that does the following two things:

  • InstallApplicationEventHandler on the second thread

  • Write a ReceiveNextEvent/SendEventToEventTarget loop to run on the second thread, with the duration set to kEventDurationNoWait. I know NoWait is wasteful, but it is in a preemtive thread - and otherwise it hangs. I’m sure there’s a fix but this worked and it was good enough for me.

From your main thread

  • make calls to agl & Carbon (ie CreateWindow) via MPRemoteCall (thread safety!)
    -Call GL as normal

[Edit]

I forgot to mention that you need to make sure you wait for InstallApplicationEventHandler to finish before you allow the first thread to create windows. Simple bug, but it took me a few hours to figure out why occasionally my program would freeze at startup so I thought I might be able to save you a few hours.

I used pthreads to do my threading. I’m aware that MPRemoteCall is part of a higher-level thread package, but the call interops with the pthread api correctly.

Hope that helps,
DN.

10

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.