remain in pressed state after revealing, even if they are no
longer pressed on the keyboard. This can have bad effects,
especially if the stuck keys are modifier keys. One has to
press and release the stuck keys again to reset the wrong state.
The fix keeps track of all key presses and releases. On FocusOut
and UnmapNotify it releases all keys that are in pressed state,
and on KeymapNotify (following a FocusIn), it sets the currently
pressed keys again. To avoid confusion in the OSG-using application
normal keys are always reported released /before/ and pressed
/after/ modifier keys.
As current key states are returned as char[32] keymap by
XQueryKeymap and XKeymapEvent, this format is also used to
recognize modifier keys and for maintaining the current
internal key state. Functions to set/clear/query bits in
such a keymap are added.
The patch was extensively tested with osgkeyboard and
FlightGear under KDE and fvwm2. It was not tested on a
Xinerama setup or with multiple windows, but as _eventDisplay
is used throughout, there should be no problems. The patch also
makes the following changes:
- removes old and obsolete handling of modifier keys in ::adaptKey().
This wasn't only unused, but also wrong (and for that reason commented
out in revision 7066). The modifier states are actually handled
in ./src/osgGA/EventQueue.cpp (EventQueue::keyPress/keyRelease).
- fixes some spelling"
The modifications I made are very small but they are absolutely usefull to use osgIntrospection with visual studio 7.1 or 8 in debug modes.
This should also solve other minor common problems (converter memory leak, virtual destructor for PropertyInfo, etc...).
I choosed two function names : Reflection::uninitialize() and Type::reset(), this can of course be changed if someone has a better idea...
I made the changes against OSG 2.2.0 public release. I tested the result with VS 7.1, VS 7.1 SP1, VS 8.0 SP1 and AQTime 5.0 on Windows XP SP2... All 4 seem to agree : they detected memory leaks before and don't anymore.
Sorry I haven't take the time to test that on linux but the changes are so small I doubt there could be a problem... I let you check that on your side :-).
I hope this will help making OSG an even more wonderfull library."
Attached is a fixed version of OverlayNode.cpp. I fixed CustomPolytope::cut( osg::Plane ) method. Bug was apparent in such scenario:
Let P1 be some random frustum polytope
Let P2 be the polytope that was created from P1 bounding box (P2 contains P1 entirely)
Then ignoring precision errors: P1.cut( P2 ) == P2.cut( P1 ) == P1. But this condition was not always met. Cut failed when some of the polytope reference points happened to lie exactly on some intersecting planes in both P1 & P2 (plane distance was = 0).
I only use CustomPolytope for my shadowing stuff so I did not test how this affects rest of OverlayNode.cpp.
----2----
Also attached is a minor precision improvement for osg::Plane intersect method (double version).
----3----
I have also one observation regarding osg::Plane - There are two intersect vertices methods (float and double flavour):
inline int intersect(const std::vector<Vec3>& vertices) const
inline int intersect(const std::vector<Vec3d>& vertices) const
I guess osg::Plane won't compile when someone changes default vec3 typedef to vec3d. Shouldn't the first method be changed to use vec3f explicitly ? Ie:
inline int intersect(const std::vector<Vec3f>& vertices) const"
pbuffer functions or exactly ask for the extensions we need to call the
apropriate glx extension functions for and around pbuffers extensions.
The glx 1.3 version of this functios are prefered. If this is not pressent we
are looking for the glx extensions and check for them.
Prevously we just used some mix of the glx 1.3 functions or the extension
functions without making sure that this extension is present.
"
carbon-implementation of GraphicsWindow. Now you can use an AGLDrawable
in conjunction with osgViewer/osgCompositeViewer."
Changes from Robert Osfield, changed std::cout to osg::notify(osg::INFO)
