Hi Robert, Thanks for the thorough response. Simply put, QtQuick is a different way to build up GUIs. It uses a hybrid CSS/JS language called QML to design a UI instead of the widget / forms approach that GUI toolkits usually employ. It is geared specially towards mobile and tablet devices.
I'm working on a couple of projects for systems which have a small touch display where typical UI design isn't appropriate. A very specific example is an in car infotainment system. I'd like to use OSG to render map data and display it in on my interface which I've built through QtQuick. Here's an example of what my interface looks like: http://prismaticproject.weebly.com/uploads/8/1/9/7/8197704/1660451_orig.png Unlike normal QGLWidgets, which the GraphicsWindowQt class uses, creating an item in QtQuick to display stuff is slightly different; there are no 'widgets'. You instead create an item, where you get access to a single paint() method where the only OpenGL functionality you have is making direct calls. All QtQuick items are rendered onto a single QGLWidget canvas. For example, I can do stuff like: // glBegin(GL_QUADS); // glColor3ub(0,0,255); // glVertex2d(boundingRect().left(), boundingRect().top()); // ... And the item would render in its own assigned space on the screen, maintaining all of its positional parent child relationships. Regards, Preet On Tue, Feb 28, 2012 at 4:54 AM, Robert Osfield <[email protected]> wrote: > Hi Preet, > > On 28 February 2012 09:16, Preet <[email protected]> wrote: >> * What do the parameters passed to the >> osgViewer::GraphicsWindowEmbedded constructor (x,y,w,h) actually do? I >> played around with the values and it had no visible effect on my >> displayed result > > They tell the GraphicsWidnowEmedded object where about the window it's > representing is in desktop coordinates. > >> * What does GraphicsWindowEmbedded do behind the scenes? Since you >> don't explicitly specify a GraphicsContext for it, does that mean it >> uses the OpenGL context of the framework you're embedding it into? > > GraphicsWindowEmbedded actually does nothing behind the scenes at all > - it's a non op class designed to make it possible to reuse the > osgViewer::Viewer and CompositeViewer classes in places that already > provide the graphics context and are strictly single threaded and have > a single window. It's really tricking these classes that a designed > to work with multi-threading and multi-context capable systems where > makeCurrent() and swapBuffers() implementations are accessible to work > without doing this operations so when calls to makeCurrent() and > swapBuffers() are made by the viewer classes nothing happens. Since > nothing happens it's entirely up to the calling app to do it for the > viewer because it can't do itself. > > Since GraphicsWindowEmbedded is design to avoid properly implementing > the key context management functions on the OSG or a subclass side it > does restrict how you can use the viewer classes. It's very much a > crude approach to provide viewer functionality, easy to get working > yes, fully capable no. You can't add the full capabilities back in > when using GraphicsWindowEmbedded, if you don't need multi-threading > or multi-context this will be fine, but if you do look elsewhere. > > Actually implementing a GraphicsWindow properly is the most powerful > way to adapt 3rd party graphics contexts with the osgViewer, and this > is done by the osgQt::GraphicsWindowQt class, as was as the > GraphicsWindowX11, Win32, Cocoa and Carbon implementations found > natively in osgViewer. > > >> * I noticed that the viewport is rendered onto the window in absolute >> coordinates. With QtQuick, when you create an item to display on the >> screen, it has a child/parent relationship and coordinates are >> relative to the parent. Moving the parent will also move the child as >> you'd expect. This doesn't happen with GraphicsWindowEmbedded though, >> probably because with QtQuick, all the elements are painted onto one >> 'canvas' (I think), and GraphicsWindowEmbedded just paints straight >> onto that. > > I know absolutely nothing about QtQuick or how you've implemented the > integration with GraphicsWindowEmbedded so I can't say anything about > this. > >> * If, instead of having GraphicsWindowEmbedded draw on my screen >> whenever I call the viewer's frame() method, is it possible to render >> the viewer camera's output to a texture that I could manually draw >> onto a quad or something? This way I don't have to specify absolute >> coordinates for the viewport like I mentioned above. I already tried >> this by rendering to an osg::Image, then painting it on the screen >> with Qt, but I have a relatively old computer and >> osg::Image->readPixels() takes too much time. My results with the >> osgscreencapture example were also pretty terrible (15-16 fps @ >> 640x480). > > If you want to do off screen rendering then this is very different > thing, GraphicsWindowEmedded is not the best thing to do this, what > you'll want is a pbuffer, osgViewer provides this. > > I really don't have a clue what you are trying to achieve in the end > with your application, or why you are attempting to use QtQuick. Might > I suggest to explain to the community what type of application you are > trying to develop, what platforms you are targeting and then let > others suggest to you which route would be best rather than picking a > non standard solution without actually saying why you've done this. > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
