Thank you for the response.
I dig a little bit in the problem. My findings so far:
- I have a thread problem (not surprising). My back thread calls
viewer.frame(). Since the window is created in the main thread, the
WindowProcedure is called from the main thread. My problem is the main
thread calls GraphicsContext::resized, so i'm accessing traits from two
threads at the same time. What i see is the effect of race condition.
GraphicsWindowWin32::checkEvents call PeekMessage, but since the back thread
doesn't own the Hwnd, it does nothing.
Then, once i know this, i implemented a ResizedCallback, in which i lock
the backthread using an Scopedlock OpenThreads::Mutex, and once i own the
lock, i call GraphicsContext::resizedImplementation. This makes the jitter
goes out, but the flicker is still there (black, cow, black, cow during
resizing). it seems i can't call resized from the main thread and frame from
the back thread, but this is only a theory. ResizedImplementation only
updates traits based on the new window size, so i don't see the
problem...either my mutex are not working as expected, or there is something
i haven't seen yet.
Also i try to sync the main thread window proc and the back thread, with
similar outputs.
And if a call viewer.frame from the main thread, then all goes well,
unless that the last input event is processed later.
I'm still have to test creating the window in the back thread, and ever
call the windowprocedure from it, but i suspect windows will not let me
create a child window in another thread than the parent.
Again, thank you for the response, it's refreshing...
2007/7/18, André Garneau <[EMAIL PROTECTED]>:
Hi Himar,
Here is some information that partially answers your questions:
>> I look at the osgViewer application. i launch it with
>> osgviewerd --window 100 100 800 600 cow.osg. (Debug version).
>> and the window popups correctly, with its happy cow. When i resize the
window, the viewer don't update the viewport until i release the mouse
>> (if you resize up the window, you see the trails of the previous
borders) I attached a screen capture. I use the osgViewer to compare it with
my own window implementation.
This is the normal (and annoying) behaviour of the Windows message loop.
Under Windows, dispatching a message involving a window move or resize will
not return from the message handler (the window proc) until the operation
has been completed (i.e. the mouse button released). During this period,
Windows keeps sending WM_PAINT messages to the window message handler to
repaint content, but since the OSG does not have control during this period
(event processing is done from the main OSG thread) nothing gets updated, so
the window content does not change. It will only get its new content once
the event handler has returned and OSG has prepared a new frame.
The fix for that would be to have a separate thread do the window message
loop processing and keep the OSG main thread preparing the next frame. In
the current code, however, the OSG main thread does both.
>> My program opens a window using GraphicsWindowWin32
(createGraphicsContext). The window can be resized. But when i resize the
window, the viewer resize also. I have compare the two codes. In my
application
>> the viewer resize during mouse moves. Ok, fine. First difference: my
app resize the viewer during, osgviewer resize the viewer after. Same window
styles, same class styles.
My understanding is that you are in fact implementing a separate thread as
suggested above. The addition of the separate thread for handling the
windows message loop would explain the difference in behaviour.
Hope this helps,
André
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Himar Carmona
*Sent:* July-18-07 7:12 AM
*To:* osg users
*Subject:* [osg-users] Win32, resizing and threads problem.
Hi,
this topic refers to OSG in Windows. Can be a bit off-topic.
have anyone been able to have an OSG viewer that can be resized,
repaints during resize and renders in a thread? I'm trying desperately now
and have a tons of problems.
I look at the osgViewer application. i launch it with
osgviewerd --window 100 100 800 600 cow.osg. (Debug version).
and the window popups correctly, with its happy cow. When i resize the
window, the viewer don't update the viewport until i release the mouse
(if you resize up the window, you see the trails of the previous
borders) I attached a screen capture. I use the osgViewer to compare it with
my own window implementation.
My program opens a window using GraphicsWindowWin32
(createGraphicsContext). The window can be resized. But when i resize the
window, the viewer resize also. I have compare the two codes. In my
application
the viewer resize during mouse moves. Ok, fine. First difference: my app
resize the viewer during, osgviewer resize the viewer after. Same window
styles, same class styles.
My scene have a black background, i read an object (cow.osg). During
resizing the scene (the viewer, the camera, don't know what) jitters
up/down, left/right, flickers black / scene. Very awful. It seems OSG is
render
frames with differents viewport settings or tratis settings. I suspect
the problem can be that i use a render thread that call viewer.frame().
viewer.checkevents don't catch any windows messages, as it is not the
owner thread of the Hwnd. And i'm also suspect that the threads are
colliding..
Any clues, tips, info? I know this question could not be directly
related with OSG. For sure it this how i set OSG. But i have fired all my
charges now. So i need a little push :(
Thanks
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
