a collegue of mine noticed that on Windows and X11 the modifier state (such as
Alt or Ctrl) would be applied one key press too late: e.g. press & hold Alt,
press a, release Alt, press a, press a would generate the key sequence a,
Alt-a, a instead of Alt-a, a, a.
The problem is also present on Carbon. Moving the call to setModKeyMask in
front of the call to keyPress fixed it for me on Carbon and X11. I suppose
that this will fix the problem for Windows as well."
* Setup proper pixel format for ATI boards (removal of WGL_SWAP_METHOD_ARB specification from the requested pixel format since unsupported by the ATI driver)
* Fix to create sample OpenGL window on the proper display device. This is the temporary window used to choose the desired pixel format. In the previous version, this window was always created on the primary display device, even though it had potentially different pixel formats compared to the target display device containing the window to be created.
* Implementation of WindowingSystemInterface::setScreenResolution() method
* Implementation of WindowingSystemInterface::setScreenRefreshRate() method
* Implementation of GraphicsWindow::requestWarpPointer() method
* Implementation of GraphicsWindow::useCursor() method and associated trait support. This can be used in two ways; first, when the graphics trait requested indicates that no cursor should be present, a new cursor-less window class is used to create the window. When a cursor-enabled window creation is requested, another window class is used. After creation of a window, it is also possible to toggle the cursor state by using the GraphicsWindow::useCursor method.
* The way the mouse behaves is now compatible with the behaviour seen on X11; i.e. when pressing a mouse button, the window where the pointer is located will capture the mouse input and release it only after the button has been released. This results in all mouse movement events being dispatched to the window where the button was pressed initially until it is released. This improves the interaction with graphics windows.
* Preparation work has been done to support the ability of moving a window from one screen to another screen and recreating its rendering context when this happens. This has been tested with a mix of NVIDIA and ATI cards and works properly. For the moment being, this feature is commented out due to changes in the core OSG libraries that have been done but need to be submitted later this week for approval by Robert.
Upcoming features
* Support for moving windows from one screen to another screen seamlessly
* Ability to set the window (i.e. the application itself creates the rendering window and passes it to the GraphicsWindowWin32 class)
* Other miscellaneous items"
---------------------------------------------------
