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"
UIView, respecting the sizes via GraphicsContext::Traits.
This helps users, who want to integrate osg into an existing ios-app
with multiple UIViews. Additinally a view-controller gets only created
if needed, set IGNORE_ORIENTATION via the WindowData-struct.
"
implement the recently introduced setSyncToVBlank-method.
Additionally I added a ToggleSyncToVBlank-eventhandler to osgViewer. I
used it to test the code, perhaps you'll find it useful and include it
in the distribution."
I also fixed the vsync implementation introduced with rev.11357 that was crashing with the Windows Error #170. So I removed your temporary /* */ around the vsync condition..."
enum DeviceOrientation{
PORTRAIT_ORIENTATION = 1<<0,
PORTRAIT_UPSIDEDOWN_ORIENTATION = 1<<1,
LANDSCAPE_LEFT_ORIENTATION = 1<<2,
LANDSCAPE_RIGHT_ORIENTATION = 1<<3,
ALL_ORIENTATIONS = PORTRAIT_ORIENTATION | PORTRAIT_UPSIDEDOWN_ORIENTATION | LANDSCAPE_LEFT_ORIENTATION | LANDSCAPE_RIGHT_ORIENTATION
};
typedef unsigned int DeviceOrientationFlags;
The main motivation for this is to easily allow the user to specifiy that the device is in a horizontal orientation rather then having to rotate the view matrix. All flags have been tested individually as well as in combinations. The default is ALL_ORIENTATIONS to keep the exiting functionality for anyone who hasn't specified WindowData for their context traits.
"
and another problem is:
example osgkeyboard is not work (keys not highlight) if user have 2 keyboard layout native and english and current user layout is native
I try to explain my changes
we need something that is identify key without modifier keys and layout -> this is UnmodifedKey
I think osg must have its own UnmodifiedKeys table. Code must be run same on different platforms. This can de guaranteed by UnmodifiedKeys table.
Mikhail Izmestev helped me. He implemented VirtualKey changes in GraphicsWindowX11"
attached you'll find the second part of the IOS-submission. It contains
* GraphicsWindowIOS, which supports external and "retina" displays,
multisample-buffers (for IOS > 4.0) and multi-touch-events
* an ios-specific implementation of the imageio-plugin
* an iphone-viewer example
* cMake support for creating a xcode-project
* an updated ReadMe-file describing the necessary steps to get a
working xcode-project-file from CMake
Please credit Thomas Hogarth and Stephan Huber for these changes.
This brings the ios-support in line with the git-fork on github. It
needs some more testing and some more love, the cmake-process is still a
little complicated.
You'll need a special version of the freetype lib compiled for IOS,
there's one bundled in the OpenFrameworks-distribution, which can be used."
Notes, from Robert Osfield, modified CMakeLists.txt files so that the IOS specific paths are within IF(APPLE) blocks.
osg::GraphicsContext, in order to give good integration with the
application's GUI toolkit. This works really well.
However, I need to share OpenGL texture resources with the standard
osgViewer GraphicsContext implementations, in particular the
PixelBuffers. This is essential for my application to conserve graphics
memory on low-end hardware. Currently the standard osg implementations
will not share resources with another derived osg::GraphicsContext,
other than the pre-defined osgViewer classes e.g. PixelBufferX11 is
hardcoded to only share resources with GraphicsWindowX11 and
PixelBufferX11 objects, and no other osg::GraphicsContext object.
To address this in the cleanest way I could think of, I have moved the
OpenGL handle variables for each platform into a small utility class,
e.g. GraphicsHandleX11 for unix. Then GraphicsWindowX11, PixelBufferX11
and any other derived osg::GraphicsContext class can inherit from
GraphicsHandleX11 to share OpenGL resources.
I have updated the X11, Win32 and Carbon implementations to use this.
The changes are minor. I haven't touched the Cocoa implmentation as
I'm not familiar with it at all and couldn't test it - it will work
unchanged.
Without this I had some horrible hacks in my application, this greatly
simplifies things for me. It also simplifies the osgViewer
implementations slightly. Perhaps it may help with other users'
desires to share resources with external graphics contexts, as was
discussed on the user list recently."
Notes from Robert Osfield, adapted Colin's submission to work with the new EGL related changes.
GraphicsWindowCocoa-implementation, which enhances multithreaded
stability, it ensures that modifications to the size of an openglcontext
is done only from one thread.
"
implementation of GraoicsWindowCocoa:
Enhancements/Bugfixes:
+ now it's possible to integrate osgViewer better into existing
cocoa-applications:
* create one or more NSOpenGLView(s) and add these to your window(s)
* create one or more NSWindows
* disable the integrated event-polling of osgViewer, and let the work be
done by Cocoa / NSApplicationRun. You'll have to run the osgViewer's
runloop in a separate thread
+ missing menu-event-handling implemented
+ added NSAutoReleasePools where necessary, this fixes some memory-leaks
+ fixed some crashes and thread-issues"
Original email from Frederic at start of thread:
"he patch attached, made from r10068, fix two things, in other of importance :
- the selected cursor is never shown ( second change in file ). Only the left arrow is always displayed.
- remove the arbitrary ( in my sense ) limitation that the user cannot choose a cursor with the same shape that one used when resizing the window. This limitation doesn't exist for X11, and we have a diverging behaviour there ( first change in file ). Flightgear use the LeftRightCursor in look around mode."
Follow up email from Frederic (with changes that finally made it into this check in:
"I've just tested Mark's suggestion and it works perfectly, even when the
cursor goes to the border then come back inside the window.
But his patch doesn't seem to be based on the last revision of the
files, or at least not on the trunk, and there are more changes than
expected in them, including some loss from the previous patches.
The patch attached is based on r10068 of
src/osgViewer/GraphicsWindowWin32.cpp and r10067 of
include/osgViewer/api/Win32/GraphicsWindowWin32"
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg23734.html
The change is source compatible with current osg code and will not affect current users, it simply adds an additional parameter to the GraphicsWindowWin32::WindowData struct constructor and defaults to the current behavior.
Attached are the files "include/osgViewer/api/Win32/GraphicsWindowWin32" and "src/osgViewer/GraphicsWindowWin32.cpp" with my changes, based on svn revision 10045. In addition, I have provided an svn patch file with the same changes for your convenience.
I have discussed the matter with my supervisor, and agreed that my company makes no copyright claim over this extremely trivial change (or to put it another way, we assign copyright to the open scene graph community.)"
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."
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"
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)
