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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
