The solution for to refactor the way that events are checked so I add a bool return type to checkEvents() method across osgViewer::GraphcisWindow, osgGA::Devive and osgViewer::Viewer/CompositeViewer classes
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.
some stuff out into DarwinUtils.h/.mm so both implementations can share
some of the code. There's even a bugfix for GraphicsWindowCarbon, which
fixes some issues with multiple windows on different screens."
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."
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)
multiple GraphicsWindows, this singleton is accessable via GUIEventEvent::getAccumulatedEventState().
Added use of this new singleton in GraphicsWindow* implementations.
Added WindowSizeHandler to osgkeyboard to help with debugging of event state
between windows.
Added and cleaned up DeleteHandler calls in osgViewer to help avoid crashes on exit.
Changed DatabasePager across to dynamically checcking osg::getCompileContext(..)
Updated wrappers.
bugs in the Carbon-implementation of GraphicsWindow, so here's another
fix for setWindowDecorationImplementation, now updates the
titlebar-height, and fixes some display-issues when switching the
decoration on/off.
"
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.
"
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.
"
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."
multithreaded-opengl-engine on os x or not. I set its default to false,
perhaps other os x users can test this setting with their data/apps, to
see if we can enable it by default.
I changed also the borderless-window-type, so expos?works correctly."
> I put this at the end of realizeImplementation; someone with better knowledge
> of Carbon programming may see a more appropriate place for the call.
I moved your code into the ctor of the OSXCarbonWindowingSystemInterface
so it get called only once. Can you test it again, if it works on your side?
I also disabled multithreaded-rendering because it slowed down the
rendering on my machine by a factor of 3. Perhaps we can make it
optional to test it on other machines.
I had some problems implementing pbuffer-support for os x and stopped it
for now until I have more time to investigate the issues.
"
+ Multi-display-support
+ automatic hiding of the menubar/dock if one of the windows intersects
the menubar/dock
Bugfixes:
+ event-handling was done by the first opened window, other windows did
not receive events -- fixed
+ mouse-coordinates were absolute, now they are relative to the window.
known bugs:
+ windows with decoration and in fullscreen-size are moved by the system
a little bit, so that the titlebar is accessible/visible. So if you want
real fullscreen-windows, don't decorate the window :)
I updated the XCode-project-file so all ported examples are linked
against osgViewer."
