Hi André, Comments indespresed below, I'll not comment on bits I have nothing to add though.
Again I have not been able to reproduce consistently this issue; for some setups, moving windows from one screen to another one will work well. The issue will only happen though when the window being moved is completely enclosed within the target screen. If part of it is still in its original window, then it will render fine (even the portion showing up in the target screen).
Sounds a bit like a Window manager or driver bug, or just fluke that it ever works and shouldn't ever work.
> 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. This is the way the Windows message loop behaves. When a window is dragged by its title bar, Windows will not return from the DispatchMessage() call until the window has been released. Since the "main" OSG thread is currently responsible for processing events (checkEvents()), the current implementation will block until control from DispatchMessage has been returned (the DispatchMessage() system call is responsible for calling the proper window event handler, based on the message content).
Is there any way to just check to see if any messages are waiting, rather than allow it to block?
To fix this, what I plan to do is have a single thread created to pump out all messages from the windows message queues and enqueue them into the osgGA event queue. This way, the main osg thread would only have to dequeue and process these messages instead of having to go the complete length and pump them out from windows and then process them. In the case of the X11 implementation, you are also pumping messages from X11 so the threading structure is similar (the main thread does everything).
I don't know if this helps, but I have been considering adding a osg::GraphicsContext* and osg::View* pointer (possible a observer_ptr<>) to osgGA::GUIEventAdapter to allow apps and windows to specify where the events came from. This might help if you are piling all the events into one EventQueue and wish to later filter it so that events end up in the appropriate windows event queue during checkEvents. One hesitation I would have about threading out events is the Producer threading of events was a source of problems when exiting from the app - getting the event loop to exit cleanly was a bit problematic as the X11 call that it was waiting on wasn't cancelable using pthread cancel. Pushing an event to X11 was a solution that Don deployed a few months back which helped the situation. I still saw occasional threading problems on exit though, but was never able to get to the bottom of them. This needn't be a problem under Windows, but its something to watch out for.
>> * 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? When a display device is not attached to the desktop you cannot create windows onto it and it shows up greyed out in the display properties window. Adding it to the desktop only requires enabling a toggle and positioning the monitor so it knows its origin in the virtual screen arrangement.
Can you do this programatically? If so I do wonder if you might end up having to expose more controls to the app to allow the position on the virtual screen.
>> * 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. Normally you would only use this for either full-screen views or windows that do not overlap. The latest window realized would be the one winning over the other ones in overlapping cases. Under Windows the particular interest for this flag is to prevent the taskbar from showing on top of a rendering window if it does not completely cover it (regardless of the taskbar settings). Its mainly useful for full-screen simulations, where its very annoying to see windowing artifacts such as the task bar auto-hiding (and un-hiding sometimes).
Perhaps the name of such a flag could be better chosen. Is possibly a WindowSystemInterface method call rather than Traits issue. OSX has the same issue with menu bars so perhaps we can figure out a common naming and placement which makes sense allround.
> 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. I personally don't favor one way or another, as long as there is a way to control these. Perhaps having a traits structure for each screen would make sense also.
I've already added the methods to WindowSystemInterface, but do need some feedback on whether we should pass in depth of the screen as well. See my other email.
> 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. Agree.
I've already added this and wired it up under X11. Not testing yet though, should work though, its pretty trivial code. I have just check these changes to Traits in, along with the setScreenResolution method. Cheers, Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
