[osg-users] set proper size to window manager at startup

[Gianni Ambrosio]

Hi All,
I have a Qt application ad I have to initialize a WindowManager with some default width and height like follows:

osg::ref_ptr<osgWidget::WindowManager> wm = new osgWidget::WindowManager(view, 1280.0f, 1024.0f, MASK_2D, osgWidget::WindowManager::WM_USE_RENDERBINS);

When the Qt application starts up then the QWidget containing the OSG view is resized properly by the Qt framework but even if I use:

view->addEventHandler(new osgWidget::ResizeHandler(wm, camera));

an osgGA::GUIEventAdapter::RESIZE event is not raised at that point. That means, every OSG windows added to the WindowManager are not resized correctly. Only when the user interactiverly resizes the window of Qt application, then a osgGA::GUIEventAdapter::RESIZE is rised and, falling into ResizeHandler::handle() methodm the Window Manager is updated with proper width and height.

Now, which is the correct way you see to solve this issue?

Regards,
Gianni

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66828#66828





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Gianni Ambrosio]

I verified that when the application starts the code falls into the following method (osgQt\GraphicsWindowQt.cpp),

void GLWidget::resizeEvent( QResizeEvent* event )

where it seems a resize event is insert into the event queue with proper width and height:

_gw->getEventQueue()->windowResize( x(), y(), scaled_width, scaled_height );

but a RESIZE event is not passed to the ResizeHandler. Can anybody see a good reason or a bug there?

Regards,
Gianni

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=66830#66830

[Gianni Ambrosio]

The problem seems to be here:

osg130-osgGAd.dll!osgGA::EventQueue::clear() Line 37 C++
osg130-osgGAd.dll!osgGA::EventQueue::setStartTick(__int64 tick) Line 212 + 0x25 bytes C++
osg130-osgViewerd.dll!osgViewer::CompositeViewer::setStartTick(__int64 tick) Line 355 + 0x1d bytes C++
osg130-osgViewerd.dll!osgViewer::CompositeViewer::realize() Line 646 + 0x31 bytes C++
osg130-osgViewerd.dll!osgViewer::ViewerBase::frame(double simulationTime) Line 678 + 0xf bytes C++
osgWidgetsTest.exe!ViewerWidget::paintEvent(QPaintEvent * event) Line 154 + 0x46 bytes C++

The first time a paint event is called, the eventqueue is cleaned up (see EventQueue::clear()) and the RESIZE event with correct width and height unavoidably lost!

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=66831#66831

[Gianni Ambrosio]

I recently moved from OSG 3.0.1 to 3.4.0 and I'm getting this unexpected behaviour only with OSG 3.4.0. In fact comparing the code of 3.0.1 and 3.4.0 I realized the clear() call in EventQueue::setStartTick() is only present in 3.4.0 code. I don't know the reason of that but from my point of view in 3.4.0 setStartTick() does more that it says: setStartTick just have to set the tick non more than that. Moreover that modification (clear()) has broken the scenaio I described.

Gianni

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=66834#66834

[Gianni Ambrosio]

I verified the clear() call has been added to EventQueue::setStartTick() method in OSG 3.1.1. Who did that can explain me please why it was required? Is there a way to move a clear() call outside the method to prevent the regression from OSG 3.1.1 onwards?

Cheers,

Gianni

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=66852#66852

[Robert Osfield]

Hi Gianni,

As a general note, I'm not the author of osgWidget so not in great position to answer specific questions about this.  Unfortuantely, the author Cedric Pinson is now busy with the javascript version of the OSG and Sketchfab so not pitching in my on the osgWidget side these days.

On 18 April 2016 at 09:49, Gianni Ambrosio <g.ambro...@gmail.com> wrote:

I verified the clear() call has been added to EventQueue::setStartTick() method in OSG 3.1.1. Who did that can explain me please why it was required? Is there a way to move a clear() call outside the method to prevent the regression from OSG 3.1.1 onwards?

It's quite a while back, but I have recall having to address bugs with event time stamps getting out of sync in certain circumstances.  As whether you are seeing a regression in osgOGA or a fix to osgGA exposing a bug in osgWidget I can't say.

Robert.

 

[Gianni Ambrosio]

OK, thanks Robert for the informations.
So, just tio summarize the case for Cedric.
When a Qt Application starts, most of Qt events (like resize, show, activate, ...) are sent to GLWidget before the OSG code handles them. GLWidget handles those events and queue them into OSG Eventqueue to be processed on the next frame() call. The problem in that the first call of ViewerBase::frame(double) calls setStartTick(osg::Timer::instance()->getStartTick()) (in realize() method) which clears the queued events. So this causes all events already queues not correctly handled.

I found that setStartTick() call is used somewhere in OSG code. I can suggest to call eventQueue.clear() before setStartTick() separatedly when needed instead of calling it directly inside setStartTick() but I'm not aware of the overall OSG code and possible consequences.

Hope this helps.

Gianni

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=66854#66854

[Robert Osfield]

Hi Gianni,

It is appropriate for osgGA::EventQueue::setStartClick() to call clear() as otherwise the queue would end up with inconsistent time stamps, as existing events would have the wrong relative time.

The only alternative to this would be to reset all the event in the queue so that their time was reset relative to the previous and new start ticks.  However, the setStartClick is something done at initialization of the viewer, before event handling is meant to kick off, it's not something that is meant for after start up.

Personally I think the problem you are seeing is in osgWidget relying upon resize events at the start of the application, it really shouldn't rely upon this.  I'm not the author though so pinpointing what it should do would require sifting through the design and implementation to see a better approach.  Unfortunately I don't have the time to do this right now.

Robert.

[Gianni Ambrosio]

I can understand you don't have time and you are not the author of osgWidgets. Anyway the case can be reproduced with osgviewerQt example. Putting one breakpoint on GLWidget::event(QEvent*) and another breakpoint on ViewerWidget::paintevent() method (the one that calls frame()) you can easily see that QEvent::Resize, QEvent::Show, QEvent::WindowActivate events fall into GLWidget::event() "before" the first frame() is called. So, from my point of view, this is not strictly a problem of osgWidgets: resize, show and activate evets are cleared from the event queue in every case and I dont' think this is correct.

Regards,
Gianni

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=66859#66859

[Robert Osfield]

Hi Gianni.

On 18 April 2016 at 13:48, Gianni Ambrosio <g.ambro...@gmail.com> wrote:

I can understand you don't have time and you are not the author of osgWidgets. Anyway the case can be reproduced with osgviewerQt example. Putting one breakpoint on GLWidget::event(QEvent*) and another breakpoint on ViewerWidget::paintevent() method (the one that calls frame()) you can easily see that QEvent::Resize, QEvent::Show, QEvent::WindowActivate events fall into GLWidget::event() "before" the first frame() is called. So, from my point of view, this is not strictly a problem of osgWidgets: resize, show and activate evets are cleared from the event queue in every case and I dont' think this is correct.

Events before the viewer frame loop have begun should be moot for what happens in the frame loop, these events may affect state but these should all be accounted from by the appropriate viewer code prior to the frame loop.  What happens prior to the frame loop is completely arbitrary and out of the viewer's directly so it's not something it should be passing on as events.

The problem here with osgWidget is that it's trying to use events prior to the frame loop starting as a means of getting state about the windowing side.  Rather than trying to second guess what the values are for a window based on events it really should be going directly to the windows themselves if it wants to account for their state.

Robert.