Hi, 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.
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. 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? Forgive me this long comment (and my grammar), my intend is to share knowledge, perhaps it can fill some future caveats... 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/
