Hi Manu,
On 6/6/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
just to be sure, the GraphicsWindowEmbedded system simply consists in
drawing a window with no border on the designed area, isn't it ?... In that
case its utility is really limited I think : there is no kind of integration
with the target windowing system (can't resize, hide/show window, etc...)...
or am I missing something ?
No you haven't missed anything, except the intent.
GraphicsWindowEmbedded does nothing, all the various *Implementation()
method that should be overirden by proper GraphicsWindow
implementations are just {} non ops. It doesn't do anything for you
in terms of creating windows, handling events or anything.
What GraphicsWindowEmbedded does do you is it gives you a means for
adapting events via the GraphicsWindowEmbedded's EventQueue, and
provides the Viewer and CompositeViewer a means for managing all the
rendering operations required to draw their Camera's.
Stick the two together and you get a way of embedding a Viewer
directly into an window that you've created and manage in your
application. Its a bit of trick in terms of getting Viewer to believe
that its got a real graphics window and can do rendering and get
events, but in reality its just doing no ops on makeCurrent() and
swapBuffers(), instead this are done by the calling app.
The usage case is more limited with GraphicsWindowEmbedded than with a
full blown GraphicsWindow implementation, with things like
multi-window and multi-threading support lost, but you still get lots
of other Viewer/CompositeViewer functionality for free. Have a look
at the present osgviewerQT and osgviewerFLTK to see how easy it is to
graft both viewer types into windows created by QT and FLTK
respectively.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
