HI Stephan,
On Fri, Jun 27, 2008 at 2:03 PM, Stephan Maximilian Huber
<[EMAIL PROTECTED]> wrote:
>> 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.
Thanks for the info. Not being driven by an event loop is absolutely
essential for visual simulation apps, so we have to figure out a way
to do it.
> 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 :)
While the current implementations work I don't think there is an urgent need.
> 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
The only selling point of quicktime for me is the movie support, as we
have lots of image plugins that work just fine already, so it'd be
movie integration that I'd see as the key thing to get moved to. I
recall the Apple API for video is now Core Video, it this right? Does
it support live and video streams?
I also feel that replacing quicktime with DirectShow under Windows is
the right way to. So it might be possible to drop Quicktime
completely once we have replacements under Windows and OSX in place.
> 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.
Once we have the plugins building we can easily tweak the alias in Registry.
> 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?
I recognize that we need some general mechanism, bit I haven't yet
thought about how we might go about implementing it. An
acceptsProtocol(..) methods at first glance looks like something that
might work out OK, one would really need to dive in a try out an
implementation to know how well it serves the purpose.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
