The impact of the bug was a memory leak that would affect multi-sampling iOS apps that allow for device rotation or window resizing in general. For our app, the leak ranged from ca. 10 MB to 40 MB per device rotation, depending on device, for the MSAA buffers. I have not been able to confirm impact for the stencil buffer. "
This issue can be reproduced:
1. Create osgViewer window,
2. Push right&left mouse buttons on the osgViewer window,
3. Move mouse out of window, and release right&left mouse buttons.
osgViewer window handle only first mouse release, as result window thinks that we did not released second mouse button.
I attached fix for this issue."
Added template readFile(..) function to make it more convinient to cast to a specific object type.
Added support for osgGA::Device to osgViewer.
Added sdl plugin to provides very basic joystick osgGA::Device integration.
What happens is this:
A view is created, and then the viewers thread is created and runs.
The setReleaseContextAtEndOfFrameHint is true.
To create a second view, the viewer is setDone(true), and we wait for the thread exit.
At this point, inside the ViewerBase::RenderingTraversals code, there are places where it reads "if(_done) return;"
The problem, is that it won't reach the code that will releaseContext().
Apparently, this driver won't let any other thread to makeCurrent(), if another thread (dead or not) has ownership. So when the Viewers is re-started, the first view won't be able to use the gc.
The change attached (against rev 13153) corrects this."
Attached are changes to GraphicsWindowIOS.mm to support setting up the new buffer type when compiling for iOS5,
also attached is a small change to FrameBufferObject.cpp to report support for packed depth stencil via the
GL_OES_packed_depth_stencil extension.
For anyone reading this you can attach a packed depth stencil to your FBO like so
_rttCamera->attach( osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, GL_DEPTH24_STENCIL8_EXT );
Luckily GL_DEPTH24_STENCIL8_EXT happens to have the same value as iOSs GL_DEPTH24_STENCIL8_OES"
Cocoa and when to use the old Carbon interface for the windowing system.
The old code had to be modified for every new OS X release to default to Cocoa.
The new code uses Carbon for <= OS X 10.4 and Cocoa on everything else."
IF(${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.7.sdk")
...
ELSEIF(${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.5.sdk" OR ${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.6.sdk")
...
ELSEIF(EXISTS /Developer/SDKs/MacOSX10.4u.sdk)
...
ELSE()
...
ENDIF()
Which is fragile because XCode could be installed into another directory than /Developer. (In case XCode is not installed into the /Developer directory CMake can automatically resolve the path via command line utility ${CMAKE_XCODE_SELECT} --print-path)
This issue bites me currently because the latest XCode (Version 4.3.1 - 4E1019) installed through the Mac App Store is per default installed in "/Applications/Xcode.app/Contents/Developer" and hence the 10.7 SDK in "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
Searching the web to find the proper way to determine the version of the Platform SDK programmatically, I found no standard way. I came up with 2 options myself:
1) Parse the path string to extract the version number
2) Read a value from the SDKSettings.plist found in the root of each SDK (e.g., "defaults read ${CMAKE_OSX_ROOT}/SDKSettings.plist CanonicalName" gives "macosx10.7")
I implemented the last option and verified that at least the following Mac OS SDKs (10.3.9, 10.4, 10.5, 10.6, 10.7) support this method. It also looks reasonably future proof. An additional benefit of this method is that it also seems to be compatible with iOS and iOS Simulator SDKs (at least for version 5.1, but I assume this also applies to older versions). This is interesting because the CMake infrastructure to build OSG for iOS currently still contains similar hard-coded paths and even requires you to manually change the cmake file to build for another iOS SDK version. In the near future I hope to address these issues, but I haven't been able to try this yet."
Now examples/osgmultitouch really works ;-)
Based on yesterdays trunk.
* It should now work with all Visual Studio Versions.
* WIN_VER is left as-is
* I added the missing declarations from a recent SDK, if not supplied by the SDK
* If someone chooses to update WIN_VER, the declarations should not break.
* All API Calls are runtime detected.
* No CMake Variable, Support is enabled automatically ."
I added AFAIK proper defaults for several Macos X Version API targets.
* In order to determine which defaults to apply, consult the CMAKE_OSX_SYSROOT variable pointing to the used SDK, not the pure existence of an SDK.
* Defaults are now:
10.7: Support Intel 32 and 64 Bit Cocoa with imageio picture reader
10.6 + 10.5: Support Cocoa with imageio on Intel and PowerPC
10.4: Carbon, Quicktime and PowerPC
Now OSG compiles out of the box for MacOSX 10.7. , tested with gcc and clang with FlightGear."
Here's another small submission for IOS, which adds unique ids to the
touchpoints, so the ids stay the same during a touch-sequence.
(and some minor code enhancements)"
10.6), which will forward all multi-touch events from a trackpad to the
corresponding osgGA-event-structures.
The support is switched off per default, but you can enable multi-touch
support via a new flag for GraphicsWindowCocoa::WindowData or directly
via the GraphicsWindowCocoa-class.
After switching multi-touch-support on, all mouse-events from the
trackpad get ignored, otherwise you'll have multiple events for the same
pointer which is very confusing (as the trackpad reports absolute
movement, and as a mouse relative movement).
I think this is not a problem, as multi-touch-input is a completely
different beast as a mouse, so you'll have to code your own
event-handlers anyway.
While coding this stuff, I asked myself if we should refactor
GUIEventAdapter/EventQueue and assign a specific event-type for
touch-input instead of using PUSH/DRAG/RELEASE. This will make it
clearer how to use the code, but will break the mouse-emulation for the
first touch-point and with that all existing manipulators. What do you
think? I am happy to code the proposed changes.
Additionally I created a small (and ugly) example osgmultitouch which
makes use of the osgGA::MultiTouchTrackballManipulator, shows all
touch-points on a HUD and demonstrates how to get the touchpoints from
an osgGA::GUIEventAdapter.
There's even a small example video here: http://vimeo.com/31611842"
To reproduce the problem I attach a minimally modified osgviewer that just prints resize events. You can check what's printed in the console when you go fullscreen and windowed a few times.
The attached version of GraphicsWindowX11 fixes the problem for me, but I'm not sure this is the right approach. Maybe you can see a fix for the problem clearer.
The only place where the RESIZE event is generated in GraphicsWindowX11 is in CheckEvents and it then depends on the ConfigureNotify message. For some reason, either ConfigureNotify is not sent when going fullscreen or the traits already reflect the latest window size."
I used the latest version available via subversion.
My fix is using some API only available on 10.4 and later. I used some preprocessor statements to gain compatibility with 10.3 and earlier using (now) deprecated API.
Only tested on OS X Lion (10.7). Please do some testing as well since I'm fairly new to OpenSceneGraph. Someone should also test the code for 10.3 and earlier."
(41e23f466d)
for GraphicWindowsIOS.mm broke the compilation for OpenGL ES 1.x as
GL_DEPTH_COMPONENT32_OES is not defined for 1.x. I added a #define-guard."
