Hi André et al,
On 1/17/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
* SEV2: When window decorations are turned on/off repeatedly, window
content may stop refreshing
Is this is windows bug or a GraphicsWindowWin32 one? What causes the
refreshing to stop? Is it that the frame loop halts all together
stalled somewhere? If so where?
* SEV2: Moving a rendering window from one display device to another
display device may cause
texturing to disappear
Is this a general Windows + OpenGL issue? Is the graphics context
maintained across windows? Or is it just the current OpenGL state
that is lost? The later might be fixable with a simple
window->getState()->reset(). Loosing a graphics context is a big
issue though, not sure how one would fix this without quite a few
extra hooks in osgViewer to catch these cases.
* SEV3: Mouse support when going from one screen to another screen
needs improvement (usability issue)
I'd like to mouse behavior to work as well as it does under X11 right
now - in that you can do a mouse drag across screens but the mouse
coordinate relative to the original position stay consistent and the
original window keeps focus. The GraphicsWindowX11 mouse handling
code has some specific code for this that might be a useful reference.
* SEV4: When a window is moved, rendering is frozen (standard
Windows-behavior). A workaround would be
to dedicate a single-thread for all window event processing
What freezes things? Is that the OpenGL calls that are frozen? Or is
it the checkEvents implementation is freezing? I'm not sure how a
separate thread would help here.
* SEV5: Display devices not attached to the desktop cannot be used.
Workaround is to add them
to the desktop until the features becomes available.
I haven't come across such a set up before, is it common?
* Implementation is missing a number of useful graphic trait options :
(needs to be discussed with Robert)
- topMostWindow flag
Forces rendering window to remain on top of other ones in all conditions
(including the taskbar even if not fully covered)
But what happens if other windows want topMostWindow flag set? Who
gets to be boss? I can image the latest window created should go on
top as being a reasonable default.
- fullScreen flag
Indicates that specified resolution in the graphic traits is
for the full-screen
(on-the-fly resolution change for display devices)
- refreshRate value
Indicates at which frequency the display device should be driven
My inclination is that GraphicsContext::Traits should just be for
pbuffer and graphics window creation, not for control of screen
properties such as screen resolution, depth or refresh rate. Such
parameters should probably go into the WindowSystemInterface such as a
setScreenResolution, setScreenRefreshRate to compliment the existing
getScreenResolution, getNumScreens etc.
I'm also thinking about putting WindowSystemInterface out into a
seperate header rather than being part of the GraphicsContext class.
I'll notify everybody if/when I make this change.
- frameRate value
Indicates the target frequency for frame update (ideally equal
to refreshRate)
The implementation will derive the vsync-divider from this.
Again this isn't for GraphicsContext::Traits as its not directly
related to pbuffers or graphics windows. For me its related to the
viewer and how it runs its frame loop so this is where such controls
should go.
- hideCursor flag
Indicates that the mouse pointer should be hidden when
hovering above the rendering window
This is related to graphics windows so is fair game for inclusion to
GraphicsWindow::Traits. Perhaps useCursor with a default value of
true would be more intuitive as the GraphicsWindow class itself has a
useCursor(bool) method.
To setup the display devices, the new osgViewer component uses the
term DISPLAY and SCREEN,
following the X11 terminology. In the Windows world, there is only one
Window Manager, so
this translates to a system allowing only one X-11 type display.
However, like X11, this
display can have one or more SCREENS attached to it (what X11 calls
screens, are known as
display devices in the Windows terminology).
When creating a screen configuration, use the Windows display ID as
the screen number *MINUS 1*.
To determine the display ID assigned by Windows:
1. Right-click on the Windows desktop
2. Select Properties...
3. Select Settings tab
4. The display ID will be present on the monitor icons.
Alternatively press the Identify button to see them on each screen.
This is an important item, the terminolgy between the various
windowing systems and the number conventions are all little bit
different. Perhaps OSX users can chime in with how Apple like to
name things.
Inline and wiki docs explaining the meaning of the various parameters
w.r.t each platform will be important.
Robert.
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
