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."
OpenSceneGraph/src/osgPlugins/Inventor/ConvertFromInventor.cpp: In member function ?virtual SbBool SoVRMLImageTextureOsg::readInstance(SoInput*, short unsigned int)?:
OpenSceneGraph/src/osgPlugins/Inventor/ConvertFromInventor.cpp:1264:16: warning: variable ?retval? set but not used [-Wunused-but-set-variable]
OpenSceneGraph/src/osgPlugins/ac/Geode.cpp: In member function ?void ac3d::Geode::ProcessGeometry(std::ostream&, unsigned int)?:
OpenSceneGraph/src/osgPlugins/ac/Geode.cpp:806:35: warning: variable ?fRep_s? set but not used [-Wunused-but-set-variable]
OpenSceneGraph/src/osgPlugins/ac/Geode.cpp:806:43: warning: variable ?fRep_t? set but not used [-Wunused-but-set-variable]
OpenSceneGraph/src/osgPlugins/ac/Geode.cpp:807:35: warning: variable ?fOffset_s? set but not used [-Wunused-but-set-variable]
OpenSceneGraph/src/osgPlugins/ac/Geode.cpp:807:46: warning: variable ?fOffset_t? set but not used [-Wunused-but-set-variable]
OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp: In member function ?virtual void osgViewer::GraphicsWindowX11::checkEvents()?:
OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp:1181:10: warning: variable ?destroyWindowRequested? set but not used [-Wunused-but-set-variable]
that the windows did not act on repaint request (WM_PAINT, EXPOSE,...)
Detailed explanation:
- I implemented requestRedraw using the push approach (not using
GraphicsWindow::_requestRedraw flag that I was considering) as there may be
multiple viewers reading the flag and fighting to reset it after the paint
request, while some viewers may not spot the request to redraw
- I made windows call GraphicsWindow::requestRedraw when they receive
appropriate message (WM_PAINT, EXPOSE, RESIZE,...)
- There were issues on Linux that windows did not want to close using x
button. Resolved by moving the test for DeleteWindow event from
swapBuffersImplementation() to GraphicsWindowX11::checkEvents(). The difficulty
was that DeleteWindow event is not coming using _eventDisplay, but through
_display.
- The last difficulty was that it is necessary to call
ViewerBase::checkWindowStatus() to set _done to true when all windows are
closed. This did not happened recently in ON_DEMAND run scheme. I put the call
to checkWindowStatus() to eventTraversal.
"
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"
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.
For example, when running FlightGear, I want the window to always have no title, so it opens full-screen without using the --full-screen option, which would prevent other windows from moving above the osg window.
I am attaching a patch I made to fix this problem."
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"
hyper keys defined already, but these modifiers were missing in
GUIEventAdapter::ModKeyMask, and the EventQueue ingored them as well.
The attached diff/archive adds the missing parts for Super/Hyper
modifier key support.
I'm aware that this might not be supported on all systems/keyboards
out of the box, but decided to submit it anyway because:
- developers are aware of differences between input devices
(Some mice have scroll wheels, others don't. Some have five or
more buttons, some have only one. Some keyboards don't have
numpads, some have AltGr, some don't etc.)
- even if someone relies on Hyper/Super in distributed software,
this is easy to fix and doesn't create lock-in conditions
- while the names Hyper/Super may only be common on X11, they are
just symbol names and not OS-specific
- even though some systems might not offer these additional modifiers
by default, it's likely that all of them have at least 8 modifier
levels internally, so it should only be a matter of OS configuration
to make them work
- having super/hyper available is useful to offer a user ways
to define local key definitions that are safe from collisions with
predefined "official" key assignments"
unconditionally sets the X11 error handler routine, replacing anything
that was previously set. This is a bit unfriendly, as the X11 error
handler is a global attribute which the application, or the GUI toolkit
being used, may well have set itself.
So I have modified X11WindowingSystemInterface to only replace the error
handler if it is the default i.e. if the application has not set it."
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
"
