Hi Stephan,
On 1/5/07, Stephan Huber <[EMAIL PROTECTED]> wrote:
I am looking at the current osgViewer-source and have several question
regarding an OS X implementation I want to code.
1.) How is fullscreen handled by osgViewer? One borderless window which
has the same size as the screen?
Yep borderless window the same size of the screen. I expect this to
work just fine at least under X11 and Windows.
On OS X there is a special
fullscreen-mode (CGL) which bypasses the window-server (which composites
all the windows in OpenGL and could slow down osg) but this has a
substantial different API than the windowing-stuff.
I'd rather not have major difference for full screen mode vs windowed mode.
Producer::RenderSurface ended up with two graphics contexts under
CGL/AGL to manage the full screen non full screen support of windows.
We could possibly do this same with a osgViewer::GraphicsWindow OSX
implementation, but we'd need to take real care of management of these
two graphics contexts w.r.t state and threading.
I do wonder if just having two GraphicsWindows would be a neater
solution, and switch between them.
If apps want to toggle between full screen and windowed mode would it
be possible to do this just with a bordless window, while apps that
just want full screen could go with a native full screen mode? This
could be done with two GraphicsWindow implementations. Opp.. just
found out your number 3 is suggestions this :-)
2.) I see a GraphicsWindowCocoa-file -- I think cocoa will not work for
implementing this stuff, because in Cocoa you give the control over the
main-loop to the system (see the osgSimpleViewerCocoa-example, main
consists of NSApplicationMain()) Next you cannot poll the os for events,
you'll get notified by the os, if new events are available, so I think
this will also make it harder to integrate osgViewer with cocoa.
This will make it harder, I was hoping that Cocoa would be more flexible.
The intent of GraphicsWindow is that the implementations should
support both event driven usage and frame driven usage. For real-time
graphics apps should be frame driven, its only interactive apps that
should ever be event driven.
3.) Is there a way to switch between different implementations at
runtime? (for example for fullscreen mode I want to use SimpleViewerCGL,
and for windowed mode I want to use SimpleViewerCarbon)
Right now there isn't a mechansim for switching between
implementations. The osg::Camera only has one GraphicsContext that
its associated with. The osg::View does support multiple Camera's and
therefore multiple GraphcsContext though, so perhaps we could manage
things be having alternative sets of slaves.
I am not a Cocoa-expert, does anybody know If I am wrong? Nevertheleess
I will start coding a Carbon-implementation of SimpleViewer the next weeks.
Implementing a SimpleViewer app will be a starting place. The real
important part is the GraphicsContext implementation though, as this
make all osgViewer::Viewer and osgViewer::ComposteViewer functionality
be usable.
Perhaps we should just have a include/osgViewer/GraphicsContextOSX and
GraphicsContextOSX.cpp with all the require contexts in place.
Oh I just thought of another way, perhaps we could have a
GraphicsWindowOSXProxy that has allows you to have two GraphicsContext
implementations at the backend and then switch allow you to switch
between. This way the viewer code wouldn't need to know
to much about the fact that their are two graphics contexts happening.
This won't be trivial though, as we'd need to handle threading
carefully w.r.t makeCurrent.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
