<div dir="ltr">Hi Gianni.<br><div class="gmail_extra"><br><div class="gmail_quote">On 18 April 2016 at 13:48, Gianni Ambrosio <span dir="ltr"><<a href="mailto:g.ambrosio+osg@gmail.com" target="_blank">g.ambrosio+osg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Robert.<br></div><div><br> </div></div></div></div>