I’m trying to compile Panda3D in OSX Lion with Python 2.7 running in 64-bit. From what I gather, the main issue is that Apple has deprecated some of the old AGL mechanisms that are used in osxdisplay, which causes compile issues. (e.g. It can’t find GetMainDevice() in osxGraphicsStateGuardian.cxx, which is an old QuickDraw call.) I’m not an OSX expert, but it seems like it shouldn’t be to hard to setup a GL context, so I figured I’d dig into it a bit to see if I can make the fix.
Then I realized that maybe someone already has or is in the process of making the change to using Cocoa, as there is already the osxGraphicsWindow.mm file which includes Cocoa. So, before I investigate further, I wanted to ask what’s going on here? Are there people working on the OSX layer to upgrade to Cocoa, or are there people more familiar with Panda who might want to help?
Perhaps osxGraphicsWindow is using some calls to Cocoa, but it is primarily using the Carbon interfaces, which Apple never bothered to port to 64-bits. Porting the whole thing to Cocoa would be a significant undertaking; there are many issues to overcome on the way, starting with the fact that Cocoa wants complete control over the application.
Thanks for your reply.
I assumed this level of OS specific code underneath OpenGL/Panda should be pretty minimal, although I have no experience working at this level beyond using glut while doing stuff like the NeHe tutorials years ago. Are there aspects of this low-level windowing that percolate out through Panda, or can it be replaced as long as the interface remains the same? For example, is Panda relying on old pixel formats or something that has fundamentally changed?
Maybe one possibility is to either use directly or borrow code or strategies from a project like pyglet, which provides cross platform OpenGL contexts. It looks like they have implementations of both Carbon and Cocoa based displays. This isn’t a pressing issue currently, but for our project we will ideally be able to use Panda with 64-bit OSX 10.7 and newer. (We are using it to test large machine learning models that potentially need access to large amounts of RAM, and we’d like to use various libraries that require python 2.7.)
In their example code you can see that Cocoa isn’t in control of the application:
code.google.com/p/pyglet/source/ … raphics.py
Under the hood, in pyglet.app.cocoa and pyglet.window.cocoa it looks like they manage to instantiate the NSApplication and associated machinery to implement the standard pyglet API.
So, I’d be willing to chip away at this. Maybe you can explain a bit more about what you think the challenges might be, and then I can research each one before doing any coding so we at least have a plan we think will work.
This would certainly be worth investigating. I’m worried about the idea of letting Panda create an NSApplication when you open a window; there are so many different points where it could go wrong. For instance, what’d happen if the user already initialised an NSApplication? This possibility might not seem likely at first glance, but there are many cases in which users create a Panda window inside a wxWidgets application, or something like that. We’d need to account for all such possibilities, and integrate it in a nice and clean fashion, without making it more difficult for people to use Panda on OSX.
I investigated this a year or two ago, but I don’t remember if I documented my findings (unfortunately), so I’m afraid there’s not much I can tell you about the specific difficulties I ran into.
It’s great that you’re willing to take a stab at it, though. Let me know how it goes; I’m willing to help you wherever I can.