Hi Himar,
>> i notice that the osgviewer windows lacks of the WS_THICKFRAME window style, as Spy++ shows, MSDN says this style is for resizing border (same as WS_SIZEBOX). Perhaps this can be helpful to anyone. Searching GraphicsWindowWin32 could give the reason. If you set the supportsResize flag in the graphics window traits, you will get the resizing borders on the window. >> Now i already have a window which resizes and updates the contents (thank you), know the problem i encounter is different and i think it have to do with threading and or doublebuffer: My first objective was integrating a OSG window inside another provided hWnd (like a child window). The window must support resizing due to layout policies or user action. Of course with any visual artifacts (difficult on WXP). So once i achieved the first goal (OSG inside an already created Window), i notice some visual artifacts happens during resizing. When moving a window, Windows will not return control to the application message loop until the window drag has been completed. So you wont get an update of the window content during this operation. I have not tried it, but I assume it is the same behavior for a resize. The fix for that would be to drive the window event message loop from a separate thread, i.e. one thread doing the rendering and another thread pumping the messages from the windows message queue. This is not implemented right now in the GraphicsWindowWin32 class; the main OSG thread is used for both. >> If I use doublebuffer the window content flicker between a black content (?) and the rendered content. If i don't use doublebuffer i see how the image is rendered. The best approach i can achieve is calling viewer.run in SingleThreaded mode without doublebuffer. Then the content looks nice. I also wanted to render only when necessary, but if i break the render loop and call frame alone, i lose mouse control. Are the render loop supporting the reading of keyboard / mouse ? Can i have mouse/keyboard 'handlers' without calling frame continuosly? I tested the osgViewerMFC approach of having the render loop apart in a thread, but it cause some artifacts to the render when i resize (my PC have 'real' parallelism due to dual core). Is there any policy in OSG implemented for synchronization in such situations? For processing only mouse events, you could call the Viewer::eventTraversal() method. If you look at the code for the Viewer::frame() method, you will see it calls eventTraversal(), updateTraversal() and renderingTraversals() sequentially. Hope this helps, André 2007/6/20, André Garneau <[EMAIL PROTECTED]>: Hi Jean-Sébastien, >> The other question is why is the window resizable by default on Linux >> and not on Windows, with the stock osgViewer? Shouldn't they both have >> the same default behavior? Yes they should. A search of the supportsResize traits in the latest SVN shows that only the GraphicsWindowWin32 and GraphicsWindowCarbon implementations seem to be honoring that flag. Looks like windows are always resizable on the Linux platform for the moment. André -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: June-20-07 3:30 PM To: [email protected] Subject: RE: [osg-users] How can I render a frame on demand? Hello André, > To have the window resizable, you just need to set the supportsResize flag > in the graphics window traits at creation time. It is false by default. Perhaps that should have been mentioned to Himar, the original poster, as he was looking for this behavior earlier. The other question is why is the window resizable by default on Linux and not on Windows, with the stock osgViewer? Shouldn't they both have the same default behavior? Thanks for the tip, J-S -- ______________________________________________________ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
