set to off. But could be activated/decativated via CMake as well as system
environment variable. I also modified src\osgViewer\CMakeLists.txt to turn
off this workaround by default as suggested."
facilitate the subclassing of Image providing interactive behaviours so as
used in the vnc interactive VncImage class.
osgViewer::InteractiveImageHandler provides an event handler that convertes osgGA
mouse and keyboard events into the coordinate frame of an image based on ray intersection with geometry in
the associated subgraph.
Changed the ordering of events processing in Viewer and CompositeViewer to allow
scene graph event handlers to take precidence over viewer event handlers and camera manipulators
This code will add two extra statistics options:
-Camera scene statistics, stats for the scene after culling (updated at 10 Hz)
-View scene statistics, stats for the complete scene (updated at 5 Hz)
Each camera and each view will expand the statistics to the right.
I also added the requests and objects to compile of the databasepager to the databasepager statistics.""
viewer.addEventHandler(new osgViewer::ScreenCaptureHandler(
new osgViewer::WriteToFileCaptureOperation("filename", "jpg")));
and the filename will be what you want. The WriteToFileCaptureOperation will add the context ID and the file number (if in SEQUENTIAL_NUMBER mode) to the file name.
(The attached also clarifies some notify messages, and corrects the comment when adding the handler in osgviewer.cpp)
I also remembered, the current architecture could allow a different CaptureOperation for each context, but currently the API only allows setting one CaptureOperation for all contexts. This could be improved if need be.
"
avoid threading issues associated with compile running in a parallel with
update/cull on the first frame.
Also added automatic recompile when a new SceneData is applied to a View.
get an excess Tab key report when switching back to an OSG
application (usually FlightGear :-). Although KDE has consumed
the Tab, it's sometimes still in the XKeymapEvent's key_vector,
and followed by a Tab KeyRelease event.
Avoid this artifact by
- asking for a "fresh" keymap (via XQueryKeymap()), rather than
using the unreliable(?) XKeymapEvent's key_vector, and by
- flushing all key events on focus-in (to avoid the KeyRelease)
After Super-press, Tab-press, Super-release, Tab-release (note
the wrong release order!) I still get an extra Tab event. But
this is not surprising and not exactly wrong either. Also it's
hard to avoid, as we can't see what happened to the keyboard
before we regained focus.
Files changed:
src/osgViewer/GraphicsWindowX11.cpp
include/osgViewer/api/X11/GraphicsWindowX11"
It's implemented in the same way that 3D Spherical Display and Panoramic Spherical Display.
You can test it running:
osgviewer --wowvx-20 cow.osg
osgviewer --wowvx-42 cow.osg
depending on the size of your Philips WOWvx display (20" or 42")
Other arguments you can use to control the 3D effect are:
--wow-content <value>
This value defines the kind of content that can be:
0: No depth
1: Signage
2: Movie
3: CGI
4: Still
--wow-factor <value>
Percentage of the display recommended depth value. Default 64, Range [0-255]
--wow-offset <value>
Amount of range behind the screen. Default 128, Range [0-255]
0: Range is shifted in the direction of the viewer.
128: Range is equally divided in front and behind the screen.
255: Range is shifted away from the viewer.
"
key, but it didn't pick up the initial state. So, if NumLock was on for
the OS at startup (LED on), it was still off for OSG. And the first
keypress turned the LED off, and NumLock on for OSG. The attached fix
picks up the state on every FocusIn, just like it was done in the last
commits for CapsLock. The difference is, that the NumLock mask isn't
standardized (e.g. 0x10 for Linux, and 0x80 for AIX), so we have to do
a reverse lookup (::rescanModifierMapping()).
Note that I could not reproduce the problem on my system, but someone
else confirmed it twice on his, and the patch fixed it for him.
Changed files:
./include/osgViewer/api/X11/GraphicsWindowX11
./src/osgViewer/GraphicsWindowX11.cpp
"
It sets osgGA's keymask when restoring keys on FocusIn, according
to the state values of XKeyEvent and XCrossingEvent. (These are
the only source for X11's current capslock state that avoids
pulling in the XKB extension.)
"
The win32 pbuffer implementation returned an error unless both the
WGL_ARB_pbuffer and the WGL_ARB_render_texture functions were present.
This was too restrictive, as a pbuffer can usefully be created without
render-to-texture, e.g. for use with glReadPixels. The osg 1.2/Producer
pbuffers worked without RTT, and osgUtil::RenderStage has all the code to
handle both RTT and non-RTT pbuffers, doing a read and copy in the
latter case.
With these changes I have successfully tested the osgprerender example
on a graphics card which supports RTT, and one which doesn't. Plus
tested in my own application.
In order to aid diagnostics I have also added more function status
return checks, and associated error messages. I have included the win32
error text in all error messages output. And there were some errors
with multi-threaded handling of "bind to texture" and a temporary window
context which I have corrected.
These is one (pre-existing) problem with multi-threaded use of pbuffers
in osgViewer & osgprerender, which I have not been able to fix. A win32
device context (HDC) can only be destroyed from the thread that created
it. The pbuffers for pre-render cameras are created in
osgUtil::RenderStage::runCameraSetUp, from the draw thread. But
closeImplementation is normally invoked from the destructor in the main
application thread. With the additional error messages I have added,
osgprerender will now output a couple of warnings from
osgViewer::PixelBufferWin32::closeImplementation() at exit, after
running multi-threaded on windows. I think that is a good thing, to
highlight the problem. I looked into fixing it in osgViewer::Renderer &
osgUtil::RenderStage, but it was too involved for me. My own
application requirements are only single-threaded.
Unrelated fix - an uninitialised variable in
osg::GraphicsThread::FlushDeletedGLObjectsOperation().
"
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"
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)
"This is a fix for the issue reported by Anders a week ago (see \u201c[osg-users] BUG?: mouse coordinate changes after window move\u201d discussion thread on Sept. 20). The issue was that the initial implementation added a few months back was not converting the window coordinates to client-area coordinates resulting in a slight offset each time a decorated window was moved (caused by the window border). This was also causing windows to move out of their assigned screen."
and
"Attached is a fix for the taskbar repaint issue that occurs when a graphics window is toggled from full-screen mode to windowed mode (as identified by Gert van Maren a couple of weeks ago).
Also included is a fix derived from the \u201cEvents from the past\u201d discussion thread that took place on July 11."
to the view to be done during syncronous updateTraversal().
This feature can be used for doing things like merging subgraphs that have been loaded
in a background thread.
Created a new GraphicsThread subclass from OperationThread which allows the
GraphicsContext specific calls to be moved out of the base OperationThread class.
Updated the rest of the OSG to respect these changes.
Stephan: "attached you'll find some modifications to the GraphicsWindow-class and
their platform-dependant implementations.
The problem:
setWindowRectangle and setWindowDecoration do not update the
traits-object, so, if you call setWindowRectangle on a
not-realized-window it will open with another size when realized later.
getWindowRectangle reports possible wrong sizes if setWindowRectangle
called before.
My solution:
split the implementation in two parts:
GraphicsWindow::setWindowRectangle will update its traits-object and
call afterwards the virtual method setWindowRectangleImplementation
(which is implemented by the derived platformspecific classess). For
setWindowDecoration I am useing a similar mechanism.
I hope you'll find the submission useful, the Win32 and X11 changes are
not tested but should work."
Changes to this made by Robert are call of resized in setWindowRectangle
instead of setting of Traits, and use of a bool return type.
changes I made:
+ put a warning in the console if a nonexistant screen is requested
+ add getters for the aglcontext and pixelformat -- I need access to
them in my own code.
"
window.
The win32 implementation is still in its original shape since I have no win32
implementation available.
I have chosen the enum approach for the first cut. That is benefitial since
the user does not need to track creation of mouse cursors for different
windows and displays in presence of multiple viewer windows.
The default set of available mouse shapes is the same set that was available
with glut. That set served many OpenGL applications well, so the hope is that
this is enough.
Even though, that implementation is still extensible:
I have digged out the way SDL defines new mouse cursors and added a still
documented out function prototype in the GraphicsWindow that can be used to
extend the current implemtation for arbitrary mouse shapes. That is not
implemented yet.
I hope that somebody with a win32 test system can catch up that implementation
on win32."
implementation of GraphicsWindow:
- usage of WindowData, you can specify an existing window to use via
osg::Traits
- implementation of setScreenResolution and setScreenRefreshRate
- implementation of setWindowDecoration when window is already created.
There seems to be a bug regarding multiple threads and closing windows,
see my other mail on osg-users.
"
Most of the code is from the osgviewer application, I have took the fullscreen handler and the threading one, and I have just added a fonctionality to be able to change the screen resolution in windowed mode."
returned from Viewer::getContexts/getWindows will be the left most window on the lowest screen number.
Added ability for StatsHandler and HelpHandler to support end users setting their
Camera's graphics context.
related support into osgViewer::Viewer and osgViewer::StatsHandler.
Added lazy updating of text in StatsHandler HUD to minimize the impact of
slow text updating on observed frame rates.
Added setting of osg_SimulationTime and osg_DeltaSimulationTime to the uniforms set by SceneView
Added frame(double simulationTime) and advance(double simulationTime) parameters to
osgViewer::SimpleViewer, Vewer and CompositeViewer.
Updated various examples and Nodes to use SimulationTime where appropriate.
* 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"
---------------------------------------------------
