Okay. I haven't looked under the covers at osgViewer (having just moved to osg 2.4 a month or so ago from osg 1.2), so it's good to know that those are two pieces that need to be re-implemented. Are there any other pieces that need to be looked at? -Eric
On Thu, Jun 26, 2008 at 9:57 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > Hi Eric, > > Thanks for the info. I too suspect forcing users to use Cocoa is a > marketing decision, or perhaps a "market engineering" decision. For > cross platform API and applications it is really bad news to have more > non portable ways of doing things foisted upon you, it just > complicates the code and makes it harder to maintain. > > W.r.t the actual implentation, going the route that Eric Wing took > with osgviewerCocoa is probably not helpful, we don't want to have a > Cocoa viewer at all, we really want just a GraphicWindowCocoa and > PixelBufferCocoa implementations that are hidden away inside the > implementation of osgViewer, something that is just quietly > implemented behinds the scenes and just does it stuff off creating > windows and getting events, but beyond this staying completely out of > the way. > > Robert. > > On Thu, Jun 26, 2008 at 2:46 PM, Eric Sokolowsky <[EMAIL PROTECTED]> > wrote: > > Apple has been encouraging developers to use Cocoa instead of Carbon for > > several years now. I'm not privy to their reasons for this change, but it > is > > probably more marketing than technical, though it may be partially > technical > > as well. > > This change will probably affect the way we render on the Mac. I haven't > > fully wrapped my head around all this Cocoa stuff yet (Eric Wing has a > much > > better grasp on this) but once the windows are set up, OSG proper should > > Just Work (TM). I tested compiling OSG for 64-bit using the x86_64 build > > architecture and, as expected, the libraries built fine except for > > osgViewer. I'm hoping that we can create a drop-in viewer using Cocoa > > instead of the current Carbon-based viewer but I just don't know. I'm > still > > too new at OSX programming stuff to really give a good answer. Perhaps > other > > Mac developers can chime in here. > > -Eric > > > > On Thu, Jun 26, 2008 at 9:36 AM, Robert Osfield < > [EMAIL PROTECTED]> > > wrote: > >> > >> Hi Eric, > >> > >> Is there any actual reason why the Carbon API is not 64bit capable? > >> Was Cocoa itself not once built upon Carbon? I'm totally perplexed by > >> Apple's decision on this, it just stuff's up lots of perfectly valid > >> apps from going 64bit for little gain. > >> > >> As for a Cocoa implementation of GraphicsWindow and PixelBuffer, is > >> Cocoa fully threadable? Are there other constraints that it'll apply > >> to the way we open, render to, and get events from the windows? > >> > >> Robert. > >> > >> On Thu, Jun 26, 2008 at 1:42 PM, Eric Sokolowsky <[EMAIL PROTECTED]> > >> wrote: > >> > I have also used OSG on 64-bit Linux without any problems. I know > >> > nothing > >> > about 64-bit Windows. On Mac OSX, OSG is not 64-bit capable because > the > >> > windowing functions used to glue OSG to the windowing system are > >> > Carbon-based, and they are deprecated and are not available for 64-bit > >> > programs. A few developers are working on transitioning away from > Carbon > >> > toward Cocoa for these bindings to enable 64-bit applications but > >> > progress > >> > is slow. My recent work to finish the osgviewerCocoa example (written > by > >> > Eric Wing) is one small step in this direction. > >> > -Eric > >> > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
