in bool GraphicsWindowWin32::setWindow( HWND handle )
there is the following if/else statement
if (_traits.valid() && _traits->setInheritedWindowPixelFormat)
....
else
setPixelFormat()
_hglrc = ::wglCreateContext(...) [1]
setPixelFormat() calls wglCreateContext() and saves the result into _hglrc which is overwritten by a second call to wglCreateContext() call at [1]
The same behavior occurs in bool Win32WindowingSystem::getSampleOpenGLContext( OpenGLContext& context, HDC windowHDC, int windowOriginX, int windowOriginY ).
The solution for this issue is to move the wglCreateContext() out of setPixelFormat() and to place it into the caller which is done to the appended file
"
- The text and dark background rectangles are now correctly placed, and
slightly resized here and there.
- All counters (vertices, etc) now use a fixed formatting with 0 digits
precision, to prevent the text from being shown in scientific notation
when the number get large (e.g. 6.34344e+6). I tested with a scene
containing roughly 4 million vertices, to make sure its stats would
display correctly.
I also made slight changes to osgcompositeviewer (attached) to aid in
testing the stats display, specifically displaying of camera and view
names."
It's a minimal change, it just calls an already existing protected method. It was trivial to subclass the handler to do it in our code, but pushing the change into OSG makes sense as it's generally useful to have it in the handler itself.
I also noticed that the handle() method was overridden from osgGA::GUIEventHandler but wasn't marked virtual. It wasn't intended that subclasses not be able to override it in turn, so I've added the keyword.""
GraphicsWindowCarbon::requestWarpPointer() places the mouse pointer in a (global?) display coordination, but it must be in a local window coordination. This problem is critical because the mouse cursor can go off a window especially when you place the window on the secondary screen.
Attached is the file to fix this problem.
I tested this modified file with the following situations (on FlightGear) and all works fine.
- two windows on two screens (each has one window).
- two windows on two screens (secondary screen has all windows).
- two windows on two screens (primary screen has all windows).
In all scenarios, warp requests (by right-click the mouse) successfully moves the mouse pointer to the center of the main window,
and it is what it's supposed to be in the flightgear."
consider these initial cpack support scripts. It is hidden behind a
BUILD_PACKAGES option so won't affect the normal user. The submission
1) set the COMPONENT attribute on all cmake install commands.
COMPONENT names are according to
http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging
2) provide cmake script and a template for creating CPack
configuration files. It will generate target for creating packages
with everything that gets "installed" (make package on unx, project
PACKAGE in MSVC) plus targets for generating one package per COMPONENT
(i.e. libopenscenegraph-core etc.).
I have temporariliy uploaded some examples to
http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHelsing
If this submission makes it into svn we can develop it to generate
rpms, installers for windows and mac (I know at least J-S don't like
these but there may be others who do ;) and even DEBs (not sure if we
can make them "ubuntu-ready" but they eventually may - at least we
could put a deb on the website)"
Before:
1. if the camera is not a slave camera
1.1 set the eventState's graphics context to the current context.
2. if the current master view is not the view which has the focus
2.1 set the current master view to be the view which has the focus
2.2 use the new master view's eventState instead of the old one
Now as you can see from this sequence, the graphics context is set on the eventState before switching to the view which has focus (and thus using another eventState). So the new eventState, in the case we need to switch views, will contain an old graphics context, not the correct one.
Just inversing these steps fixes the problem:
1. if the current master view is not the view which has the focus
1.1 set the current master view to be the view which has the focus
1.2 use the new master view's eventState instead of the old one
2. if the camera is not a slave camera
2.1 set the eventState's graphics context to the current context.
Now, the eventState will refer to the correct graphics context in both cases.
Attached is a fixed CompositeViewer.cpp (based on today's SVN) which does this. Note that some other things are done in the 1. and 2. cases, but they have no influence on each other so they can just be swapped without problems.
"
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."
parts of their scene graphs. Within these common part some nodes have
event handlers which use the action adapter argument to the event
handler to determinate which view received the event.
Here is the problem, osgViewer::CompositeViewer::eventTraversal sets
the action adapter field in the EventVisitor always to the last view
which received an event, instead of using the view which actually
received the event, so determination of the correct view does not work.
I looked at the code a bit, and moved the code for setting the action
adapter to a IMO better place"
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
