Hi Glen, I think this might be a case of fixing a bug that reveals bugs elsewhere. The change that I merged wasn't written by me (I have to defer to Windows users for Win32 support), the svn log should reveal the reason for the change. Just disabling in the case of x=0, y=0 isn't the right way to hack a fix in as this itself would just lead to even more odd workarounds.
One possible route to get the old functionality would be to have flag in Traits to say whether the call to areWindowDimensionsChanged() and resized() should be done. Another route might be to have a CMake toggle. As for other back port features from OSG-3.4.0 to OSG-3.2.3 just because of this one issue, well this is just creating a new local branched version with more changes relative to 3.4.0 and 3.2.3 than just a local patch of OSG-3.4.0 would do. If you need to hack OSG-3.4.0 in small way in the short term this would be better than back porting. For proper long term solution we'll need to come up with something that doesn't try to hack behaviours on/off with certain "magic" setting of existing values. If there are inconsistencies in behaviour these need to be enumerated and together we can try to work out a solution. Robert. On 23 October 2015 at 20:05, Glen A Johnson Jr. <[email protected]> wrote: > Robert, > > I would agree that this points to an inconsistent use of Traits between > application types however, > > If you pass in the actual window values and not 0 based values there will > have to be other changes in the osgViewer library made to support this as > the graphic will be offset from the window. (I know because that was the > first thing I tried). Also you are saying to anyone that has an MFC > application developed prior to OSG 3.4.0 (although this change is really an > winapi issue not MFC) that they can not upgrade to 3.4.0 until someone > figures out what changes need to occur in the osgViewer library and > published them. At that point the developer must work modifications into > their applications in order to upgrade to 3.4.0. I have already noticed > users such as [email protected] are backporting items from 3.4.0 to > 3.2.3 over this issue. A simpler solution to the issue than what I sent you > would probably be to remove the call to areWindowDimensionsChanged() and > resized() assuming the first returns true in the GraphicsWindowWin32 > ::init() method. I can’t really conceive of a use case where a window is > resized before it is initialized. This check is not in prior versions of > OSG. > > > > Glen Johnson > > Phone: 321-696-3122 > > Email: [email protected] > > > > *From:* osg-submissions [mailto: > [email protected]] *On Behalf Of *Robert > Osfield > *Sent:* Friday, October 23, 2015 6:57 AM > *To:* OpenSceneGraph Submissions <[email protected] > > > *Subject:* Re: [osg-submissions] OGS 3.4.0 - The view provided by OSG is > incorrectly positioned within window that has been previously created in > Windows outside of OSG > > > > Hi Glen, > > > > I have just done a review of your changes and have come away with the > feeling that the changes indicate problems elsewhere in the set up of the > Traits being passed in when an existing window is provided. It looks to me > like the Traits x and y values should be set to the values of the actual > window being passed in, with the x and y set to the top left of the windows > position, not to 0,0 as the MFC example does. > > The Traits::x,y,width, height are not viewport values in window > coordinates, they are coordinates of the window itself relative to the > desktop own coordinate frame. > > It feel like the OSG's MFC example is where the problem lies and this is > where the problem should be fixed. Same applies to client applications. > > Robert. > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
