Re: [osg-users] Review of osgQt changes.
Martin, my only point was that a QSurface cannot be created (as it is a pure virtual class), and the only available way to get one is to create a class that inherits a QWidget and the QSurface, or to use a QWindow (which already inherits QSurface). Cheers, Kristofer -- Kristofer Tingdahl, Ph. D. CEO dGB Earth Sciences ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
Small update for ya'll, I'm done with my updates and I am in the tweaking mode right now. In qt5, they do indeed have a QSurface class, but as far as I can see it is only inherited by QWindow, and as it is not stand alone (a couple of functions = 0) one would have to create an inherited class, something that would be inheriting QWidget and QSurface. Is this what you thought of Martin? So far, I am still using the QGLWidget class, though the setup is such that other implementations are possible. - Kristofer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
Hi, I didn't yet investigate, but as far as I understood, you don't need to subclass QSurface. You can create a QOpenGLContext object in the render thread and a QSurface in the GUI thread, then do context-makeCurrent(surface) to let the context render to the surface. After that, the two objects don't have to communicate, window resize events can be sent to the gl thread via signals/slots. Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51206#51206 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
Martin, all. That is indeed great news, but we would need to maintain Qt4 compatibility for a number of years ahead. It also confirms the idea of a base-class in osgQt::GraphicsWindowQt::WindowData that would be inherited by various implemtations, where one would be Qt4, one Qt5 and one with something else. As there has been few comments on my last e-mail, I will go ahead and make an updated proposal. I'll keep you posted. Cheers, Kristofer -- Kristofer Tingdahl, Ph. D. CEO dGB Earth Sciences ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
Hi, I am just learning about the changes to the OpenGL integration in Qt 5. The new way of dealing with OpenGL seems to be a lot less retarded than the QGLWidget way. You can simply create a QOpenGLContext object in the render thread and a QSurface object in the GUI thread and do context-makeCurrent(surface). No opengl calls are done implicitly by Qt. So maybe it would be wise to simply leave the nightmare that is Qt4/OpenGL integration behind us and start anew :) Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51048#51048 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
Dear Wang, I agree that the relationship of GraphicsWindowQt and GLWidget is confusing. Other windowing interface like GraphicsWindowWin32 can either create its new window or accept an existing one for the rendering context use. An ideal result in my opinion is that we can directly set a QGLWidget as an OSG window using Traits::inheritedWindowData, but the event handling must be overrode, for example, using installEventFilter() to make sure OSG can communicate with Qt window. In this way maybe we will not have to use any adapters but only send a QGLWidget pointer to the traits like: osg::ref_ptrosg::Referenced windata = new osgQt::GraphicsWindowQt::WindowData(qtWidget); traits-inheritedWindowData = windata; osg::GraphicsContext* gc = osg::GraphicsContext::createGraphicsContext(traits.get()); And thus remove present GLWidget class and provides a clear solution to Qt developers. What do you think about that? This is a similar idea to what we have right now, so I am in favor of it. In the proposed code, the WidgetAdapter handles all events to from the widget by installEventFilter. In your proposal there is essentially a merge between my WidgetAdapter and osgQt::GraphicsWindowQt::WindowData. The only thing I would want to add would be to make WindowData a virtual class, with specific implementations in the subclasses (i.e. one for use with the QGLWidget and one for indirect viewing with the QWidget (or QBitmap)). The only worry I have, and I cannot judge the implications, is that there seems to be a workaround of the QGLWidget's events, where there are events that are delayed and processed later. If this workaround is needed, then there are no other options than to inherit QGLWidget. Given this, a possible update of my proposal would be: 1. Merge the WidgetAdapter into the GraphicsWindowQt::WindowData. This class would handle the normal events from Qt to OSG (through an installEventFilter) and also provide the interface for GraphicsWindowQt to control the Qt part. 2. Create a quite thin osgQt::GLWidget class that only handles the delayed events. 3. Make a osgQt::GLWidgetAdapter that inherits GraphicsWindowQt::WindowData and can be constructed with a osgQt::GLWidget. Then later, once the infrastructure is in place, I may then create other subclasses of GraphicsWindowQt::WindowData for my indirect viewer. Any comment on such an updated proposal is welcome (before I start coding). One question I have is (as being new to OSG), is how much respect (or not) should be given to the current interface. If we change too much, then all application developers would have to adapt their code. This may be minimized by retaining the old interfaces and fixing things under the hood, but depending on the extent of the redesign that may or may not be possible. Best regards, Kristofer Tingdahl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
Hi, I have made a number of changes. I am not fully done yet, but I want to use this a a starting point for a discussion. My updated files are found at https://docs.google.com/folder/d/0B_4ZHt6ZZHE9ZTgycmQzcm9fVkk/edit Here is in brief what I have done: 1. I have made a new class osgQt::WidgetAdapter. The purpose of it is to serve as a bridge between any QWidget (not only QGLWidget) and the QGraphicsWindowQt. All access to the context and the realization is handled through the interface of the WidgetAdapter. The actual implementation of the WidgetAdapter is done in its subclasses. So far, I have made only one subclass (for the QGLWidget), but the plan is to make one for the indirect viewing later on. The creation of the WidgetAdapteralso made it necessary to move some functionality into that class from the QGraphicsViewerQT, such as switching the context. 2. I have modified osgQt::GLWidget to inherit both the QGLWidget as well as the WidgetAdapter. Quite honestly, I do not want this double inheritance, and I would want it to inherit only osgQt::WidgetAdapter, and have a widget rather than being one. The delayed execution does however mandate the inheritance as the processDeferredEvents requires access to the QGLWidget::event() function. Hence, that still remains in the osgQt:: GLWidget. Also, I suspect that a lot of client code counts on osgQt:: GLWidget being a widget. All other event-handling (apart from the delayed one) is moved into the osgQt::WidgetAdapter, which gets the events through it's _receiver, and sends them to the graphics-adapter. I did not initially want the osgQt::WidgetAdapter::_receiver setup, but since osgQT::GLWidget inherits QGLWidget, I cannot let osgQt:: WidgetAdapter inherit QObject and receive the events directly. The example code works, my application (OpendTect) works. I do however have a couple of questions: 1. I never grasped the complexity of QGraphicsViewerQt::init, especially where we get the context from the traits, and gets the window, and then the osgQt::GLWidget from it (around line 550). It requires the QGraphicsViewerQt to have an getGLWidget just because of this, so I have reluctantly kept that function. 2. There were some context-handling that I did not fully grasp: In GraphicsWindowQt::makeCurrentImplementation() we did not check if the current context was identical to our context, while in GraphicsWindowQt:: runOperations() and swapBufferImplementation we did. I have kept this functionality with a bool on osgQt::WidgetAdapter:: makeCurrentImplementation, while I have feeling that this distinction is bogus, and the boolean argument can be dropped. 3. Who should own the Adapter? If it is a widget (as it is now with osgQt ::GLWidget), then it normally owned outside, while if it not a widget (which is what I want), then it would ideally inherit osg::Referenced. There are also a few more systematic changes I want to do on osgQt (which are not done yet). 1. On the CMakeList.txt level, I would want to have an option whether to use optimized Qt or not. We have both in our environment, and today it uses debug-qt with debug-osg and release-qt with release-osg. Most often we are not debugging qt, and it I'm thinking of an option: Use optimized qt. Default would still be what it is today. 2. I want to have support for global namespacing in Qt. Qt has support for always putting all Qt classes in a namespace, and we are planning on using that to avoid clashes between developers making plugins to our system and who want to use another Qt than we do. It would mean we make a set of macros that add the namespace in front of all Qt classes. Comments and suggestions are welcome! - Kristofer Tingdahl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
Hi Kristofer, I can't remember the exact time I wrote the GraphicsWindowQt class, maybe two or three years ago. I designed it along with the OpenThreads for Qt to make OSG's threading and windowing APIs compatible with Qt so that to later migrate to Symbian/Meego... But then iPhone and Android change the world and the plan is deprecated. :-) But Qt integration is still a very interesting and valuable topic nowadays and thanks to the contribution of the whole community, the GraphicsWindowQt class is now usable for some practical uses. I myself also use Qt in some client projects and think of integrating OSG with QML as well as some Qt 5.0 new features (e.g., the Qt3D module) some time later. I agree that the relationship of GraphicsWindowQt and GLWidget is confusing. Other windowing interface like GraphicsWindowWin32 can either create its new window or accept an existing one for the rendering context use. An ideal result in my opinion is that we can directly set a QGLWidget as an OSG window using Traits::inheritedWindowData, but the event handling must be overrode, for example, using installEventFilter() to make sure OSG can communicate with Qt window. In this way maybe we will not have to use any adapters but only send a QGLWidget pointer to the traits like: osg::ref_ptrosg::Referenced windata = new osgQt::GraphicsWindowQt::WindowData(qtWidget); traits-inheritedWindowData = windata; osg::GraphicsContext* gc = osg::GraphicsContext::createGraphicsContext(traits.get()); And thus remove present GLWidget class and provides a clear solution to Qt developers. What do you think about that? Wang Rui 2012/11/8 Kristofer Tingdahl kristofer.tingd...@dgbes.com The example code works, my application (OpendTect) works. I do however have a couple of questions: 1. I never grasped the complexity of QGraphicsViewerQt::init, especially where we get the context from the traits, and gets the window, and then the osgQt::GLWidget from it (around line 550). It requires the QGraphicsViewerQt to have an getGLWidget just because of this, so I have reluctantly kept that function. 2. There were some context-handling that I did not fully grasp: In GraphicsWindowQt::makeCurrentImplementation() we did not check if the current context was identical to our context, while in GraphicsWindowQt ::runOperations() and swapBufferImplementation we did. I have kept this functionality with a bool on osgQt::WidgetAdapter:: makeCurrentImplementation, while I have feeling that this distinction is bogus, and the boolean argument can be dropped. 3. Who should own the Adapter? If it is a widget (as it is now with osgQt::GLWidget), then it normally owned outside, while if it not a widget (which is what I want), then it would ideally inherit osg ::Referenced. There are also a few more systematic changes I want to do on osgQt (which are not done yet). 1. On the CMakeList.txt level, I would want to have an option whether to use optimized Qt or not. We have both in our environment, and today it uses debug-qt with debug-osg and release-qt with release-osg. Most often we are not debugging qt, and it I'm thinking of an option: Use optimized qt. Default would still be what it is today. 2. I want to have support for global namespacing in Qt. Qt has support for always putting all Qt classes in a namespace, and we are planning on using that to avoid clashes between developers making plugins to our system and who want to use another Qt than we do. It would mean we make a set of macros that add the namespace in front of all Qt classes. Comments and suggestions are welcome! - Kristofer Tingdahl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
HI Kristofer, On 6 November 2012 15:28, Kristofer Tingdahl kristofer.tingd...@dgbes.comwrote: I want to propose some design changes in osgQt, so it will support both direct and indirect rendering (i.e. both directly to a screen-based context as well to a bitmap which is painted on a widget). These changes will make it possible to use advanced features also on remote displays. I have an early draft design proposal, and it would be good to discuss it with someone (preferably the one who wrote osgQt) before proposing the changes to be merged into osgQt. So, if anyone wants to speak up, write me an e-mail and we can take it from there. osgQt is a composite work as in the work on a number of contributors, with them either contributing new classes or refactoring or simply fixing bugs. Given this If you are happy discussing in public I would say just post the proposal to osg-users and look to start up an open discussion. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Review of osgQt changes.
Hi,Kristofer I also work on integration osg in qt and my primary goal is to use composite viewer to render in embeded window and also on secondary secondary window without qt. Now is the main problem is RTT render and multithreaded environment. Also check my submissions to have forward context on X11 I think It's better to discuss all things in forum format. And maybe for begining you will post your code here to see changes. Thank you! Cheers, Roman -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50999#50999 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
