Andreas wrote: >I have the port working again. But it only runs fullscreen and has no >mouse support.
Well, that's a start isn't it? >Sounds good. The problem with Cocoa is, that according to Apple >documentation the main thread is responsible for processing all >events. Threads can pass events to the main thread but basicly the >cocoa main loops has to be in the main thread. Right, that's the general approach in OSX. Almost all GUI functions in OSX are not thread safe in the sense that OSX expects them to be called from the main thread, which is the one running the central event loop. >(DirectFB starts a thread for every input device, which basically >consists of a loop waiting for events and translating the system >specific events to DirectFB events.) I think that is not necessary in OSX. The OSX event loop will provide all input events. Additional threads can send custom events to the main event loop and reverse, but all OS events are delivered to the main loop. >SDL solved this problem by including SDL_main.h which redefines main >() to SDL_main() and by linking to SDL_main.a which includes the main >which initializes the cocoa stuff. >I wanted to get around this somehow. I would suggest this, too. Even if Cocoa appeals most to UNIX people, I think it's the wrong layer for a low level libraray. Cocoa is a high level GUI application framework tied closely to Objective C, which means you are running the Objective C runtime, and brings in a lot of baggage that is not needed in this case. >The OSX APIs have maybe, I guess about 10 ways to open a window >(Cocoa, Carbon, Obsolete "Toolbox" Stuff, Sprockets(?), OpenGL, >GLUT, ...). >That's confusing. I would target Carbon, which is the C based procedural, modernized version of the old Toolbox API which got deprected more and more like Sprockets. GLUT is to limited beyond OpenGL samples. OpenGL is interesting because it's AFAIK the fastest graphics environment on OSX, but you need support from the GUI layer for windows and events anyway, so it's Cocoa or Carbon again, which both support OpenGL, which is called NGL for Cocoa or AGL for Carbon. >What I did right now is to take old APIs which looked easy to me. And >I got it running in a few hours back then. Yep, that's the advantage of the old Toolbox stuff. It's simple and well documented, where Carbon is more complicated and appears a bit baroque sometimes. Also the documentation is a bit "dense". >What I use for input is WaitNextEvent(). That can be migrated to ReceiveNextEvent() without major problems. > To switch the mode and get >the pointer to the framebuffer I use: >CGDisplaySwitchToMode() >CGDisplayCapture() >GDisplayBaseAddress() >CGDisplayBytesPerRow() That's the lowlevel lib below the window manager and that works fullscreen without windows only. With windows things get complicated because the OSX window manager likes to be in control very much and is OpenGL based itself. AFAIK it's implementation uses textures for windows which are moved around the main and VRAM as needed. Everything is double buffered at least. >Can you suggest a way to open a windows and get a pointer to its >buffer (doublebuffered if possible)? Without using Cocoa. No, not yet. I will consult Apple Mailing lists on this topic, in case there is a low level possibility I don't know yet. Do you need one window for a DirectFB context or do you want to map many DirectFB windows to OSX windows? >Another thing to keep in mind is that the thread which opens the >window and switches modes, configures graphics stuff etc, is not the >thread in which events are processed. AFAIk this does not work on OSX. >Basically DirectFB, coming from the linux embedded world, has a >unixish device view on the hardware (framebuffer device (+gfx >hardware registers), input devices, etc) and was not designed to run >on other operating systems which have a much more integrated high- >level view on everything, like Cocoa. However, of course we can work >around it somehow... I see. I probably don't understand enough about the structure of DirectFB and what are the costs of different approaches. If I get it right DirectFB runs "collector threads" for hardware devices which send events to main thread for processing. Can this be removed for OSX and simply replaced by the carbon ReceiveNextEvent() in main thread which provides all events? Hope this helps a bit, Christian _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
