I am looking for some information about rendering child windows in specific about how OpenGL interop with GDI. The problem that I have is that I have basically is that I have two windows, first, the main windows are created in qt, and inside of qt, a child window is hosted that leverages an OpenGL renderer.
Now what I wanted to do is to host an overlay on top of my OpenGL window, so I use that to overlay the OpenGL window. The problem that I am having is that when I render with OpenGL, the OpenGL generated graphics seem to obscure the graphics area including and effectively undo the graphics composited by qt.
In the image below the blue area is the qt overlay, in that picture I'm using GDI (BeginPaint/EndPaint) so and the windows seem to interact fine. That is, window order seems correct, the client region is correct. The moment I start to render with Opengl the blue area gets replaced with whatever OpenGL renders.
What I did I basically created to create the overlay I created a second frameless, topmost QMainWindow, and once the platform HWND was initialized I reparent it. Basically I change the new windows parent to be the same parent of my OpenGL window.
What I believed this would do is that the every window, gets drawn separately and the desktop composition manager would make the final composition and basically avoiding the infamous airspace problem as documented by Microsoft in their WPF framework.
What I would like to know is what could cause these issues? At this point, I lack understanding why once i render with OpenGL the pixels by qt overlay are obscured, even though windows hierarchy should say make them composited. What could I do to accomplish what I want?
Mixing OpenGL and GDI drawing on a shared drawable (that also includes sibling / childwindows without the CS_OWNDC windowclass style flag) never was supported. That's not something about Qt, but simply how OpenGL and GDI interact.
But the more important issue is: Why the hell aren't you using the OpenGL support built right into Qt in the first place? Ever since Qt-5 – if available – uses OpenGL to draw everything (all the UI elements). Qt-5 makes it trivial to mix Qt stuff and OpenGL drawing.
Related
I'm creating an application, which interacts with OpenGL via QOpenGL* classes. The graphics is shown through a QOpenGLWidget, which is placed in a UI-form.
Now, there is a library for CAD purposes (Open CASCADE), an OpenGL interface of which requires a handle to the render window. The question is: can I somehow say the library to render everything to the mentioned widget?
In other words, is there a way to interpret the widget as a native, probably, platform-specific (HWND here) window, so that the library renders its own stuff exactly there?
Thanks
QOpenGLWidget is not the same thing as QGLWidget.
The classical approach for embedding OCCT 3D viewer, which you can find in Qt IESample coming with OCCT, creates QWidget with unique window handle flag, takes this window handle and ask OCCT to take care about OpenGL context creation for this window. This is most straightforward, robust and portable way with one limitation - Qt will not be able drawing semitransparent widgets on top of this QWidget. This is not a limitation of OCCT, but rather limitation of Qt Widgets design.
QOpenGLWidget was intended to solve this limitation by allowing to mix custom OpenGL rendering and normal widgets. The integration of external OpenGL graphics engine, however, became more complicated and fragile. It is not very helpful stealing winId() from QOpenGLWidget, as rendering content is expected to be drawn not into window itself, but rather into OpenGL framebufer object (FBO), created by QOpenGLWidget - see QOpenGLWidget::defaultFramebufferObject() property.
External renderer is expected to render into this FBO for proper composition of Qt widgets. Luckily, OCCT is flexible enough to allow such integration. Unluckily, such integration requires some knowledge of OpenGL, as well as its usage by Qt and OCCT.
For that, you need to ask OCCT wrapping OpenGL context already created by Qt (for that V3d_View::SetWindow() provides an optional argument of type Aspect_RenderingContext, which corresponds to HGLRC on Windows and can be fetched using wglGetCurrentContext() within rendering thread) as well as FBO created by QOpenGLWidget (for that, OCCT provides OpenGl_FrameBuffer::InitWrapper() and OpenGl_Context::SetDefaultFrameBuffer() methods, as well as OpenGl_Caps::buffersNoSwap flag to leave window buffer swapping management to Qt).
OCCT doesn't come yet with a sample using QOpenGLWidget, but you can find also qt/AndroidQt sample implementing similar thing for embedding OCCT 3D Viewer into QtQuick application.
After some investigation, I found that method QOpenGLWidget::winId() returns the correct handle. It's been found out only now, because the rendered scene disappeared immediately, leaving a black picture instead. However, when the viewport is resized, the scene returns back (and disappears again, though). Looks like Open CASCADE has problems with Qt 5 OpenGL implementation, since QGLWidget didn't have such problems, as far as I know.
I need to create a GUI with a file menu and menu in which the user can input parameters. The parameters are then used for drawing rectangles in a canvas which is part of the application window. Is there a way to scale the OpenGL subwindow to just one part of the screen and the parameter input to the other? The application needs to be written in C++.
Is it possible to create a GUI with QT and draw the rectangles in the same window using OpenGL? If not, what is the common way to integrate a GUI with OpenGL? (or any other graphics library which I can use to draw rectangles from points as easy as possible)
EDIT: I am not sure If OpenGL is necessary or there is a way to paint the rectangles on the canvas like you can in Java with paintComponent().
I have never used QT before so I am not aware of its capabilites.
you can use opengl window singly or use this in the common mainwindow. previous example (in first answer) show how to use opengl window in qt singly and without communication with other components of Qt (like menu, toolbar and ...). but you can add a opengl window to a mainwindow (like other widget) and use it alongside other widgets . this example can help you.
Yes, using OpenGL together with Qt is absolutely possible. There is even an example for that and Qt provides classes for a more object oriented way of using OpenGL. Have a look here (Section "OpenGL and OpenGL ES Integration") for more details.
I was looking at how sometimes when you right click, the menu goes outside of the window.
Is this implemented with a separate window? If so, how can I get this functionality. I am trying to use GLFW, but I understand if it isn't possible.
Currently I am on windows, but I like keeping my options open, which is why GLFW would be preferable.
I noticed that GLUT has such a feature. If you are confused to what I am looking at then look at that.
Thanks for any help!!
Overlapping menus (in MS Windows) have to be implemented as a new top-level window, you would have a new OpenGL rendering context and draw the menu in that space - yes, it's a fair bit of work all for the edge-case of a menu overspilling the parent window,
However this isn't often a problem in OpenGL programming because if you're working on a full-screen game then the menu will always be displayed within the main window, and even if it isn't a full-screen a game your users really won't notice them as games tend to use different UI concepts like radial-menus which wouldn't overspill the parent window.
Or if you're working on a non-game title, chances are it isn't full-screen and is going to be an OpenGL rendering area within a larger application that is rendered using a native UI toolkit (e.g. 3ds Max, AutoCAD, etc), in which case no problem: just use native menus.
You can, of course, use native menus in an OpenGL application anyway, provided you do the necessary plumbing for native window messages.
I'm porting a small graphics engine from DirectX 9 to OpenGL. The engine uses SDL (now ported to 2.0) to manage input and window creation.
I want to know how to correctly handle window events for both OpenGL and DirectX. I'm interested in these for Desktop platforms (linux, OSX and windows)
Window resolution change
Full screen to windowed / windowed to fullscreen handling
Alt+tab handling -
I've tried to search through the net but information is quite not focused in one place. I imagine many others faced the same problem before.
Are there any resources to read guidelines on that kind of handling for my engine?
Is it possible to handle resolution change without losing transfered resources to the renderer system in both OpenGL and DirectX?
Window resolution change
OpenGL itself requires no special treatment for this. Unfortunately SDL goes through a full window reinitialization, including the OpenGL context on a window size change, which means, that all OpenGL state objects (that is, textures, vertex buffers, shaders and so on) are lost.
This is however a limitation of SDL.
Personally I thus prefer GLFW for creating a OpenGL window and context. You can still use SDL for other things though (like audio, networking, image loading and such).
Full screen to windowed / windowed to fullscreen handling
The is effectively a window size change as well. See above.
Alt+tab handling -
OpenGL requires no special effort for this. Just minimize the window when Alt+Tab-ing out and stop the game loop. When the window gets restored just continue the game loop.
I have a large OpenGL canvas in a Visual C++ MFC application. An edit box control sits over the OpenGL canvas. However, whenever the OpenGL canvas is redrawn, it obliterates the part of the edit box which sits above it, ignoring the specified window Z-order. How can I prevent this?
You don't.
Having other windows interact with an OpenGL window is not a good idea. They don't interact well; it's best to keep child windows clear of OpenGL windows.