[osg-users] 64bit, OS X, (was: Re: Warning on 64bits: cast to pointer from integer of different size)

[Stephan Maximilian Huber]

Hi Robert,

Robert Osfield schrieb:
> 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?
Not all carbon is depreceated, only stuff which has something to do with 
the UI. So windows, menus, buttons, etc should be done with cocoa. Some 
parts of Cocoa are based on Carbon AFAIK, e.g. the event-handling code.

Cocoa is fully threadable, one nitpicking problem will be the main-loop. 
Most of the cocoa applications call NSApplicationMainLoop (don't know 
the exact function-name) instead of doing it's main loop by hand. This 
could be get tricky but it should be doable.


I've started to refactor the GraphicsWindowCarbon-implementation so we 
can use parts of the code (WindowingSystemInterface, MenubarController) 
from both implementations. But there's a lot of work to do, and I am 
busy like hell :)

The quicktime-plugin is also not 64bit savvy, E. Wing has coded a 
replacement called ImageIO, but it has no movie- or live-video-support 
and works only for quicktime.

                   | win32 | darwin 32bit | darwin 64bit
-------------------+-------+--------------+--------------
quicktime-image    |   x   |      x       |
quicktime-video    |   x   |      x       |
quicktime-live     |   x   |      x       |
imageio            |       |      x       |       x

So, we need a couple of defines to route to the correct plugin from 
osgDB:Registry, perhaps we should refactor the quicktime-plugin into 
three spearate plugins, one for image, one for video and one for live-video.

I suggest also a new virtual function to handle network-protocols. 
Quicktime can stream movies from http and rtsp, but the current solution 
in osgDB::Registry will reroute the request to the net-plugin.

Something like

class ReaderWriter {
    virtual bool acceptsProtocol(const std::string& protocol) { return 
false; }
}

Implementations can override this method, and if no plugin handles the 
given protocol, the net-plugin can handle these per default.

What do you think?

cheers,
Stephan