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.
Related
I'm trying to port the code from https://github.com/eryar/occQt to gtkmm, by creating a custom widget and overriding the Gtk::widget::on_realize() method like
void OccView::on_realize() {
// Create Aspect_DisplayConnection
Handle(Aspect_DisplayConnection) display_connection = new Aspect_DisplayConnection();
// Get graphic driver if it exists, otherwise initialize it.
Handle(Graphic3d_GraphicDriver) graphic_driver;
if (!graphic_driver) {
graphic_driver = new OpenGl_GraphicDriver(display_connection);
}
// Get window handle. This returns something suitable for all platforms.
Window x_window = GDK_SURFACE_XID(get_native()->get_surface()->gobj());
// Create window for platform.
Handle(Xw_Window) xw_window = new Xw_Window(display_connection, x_window);
// Create V3dViewer and V3d_View
mViewer = new V3d_Viewer(graphic_driver, Standard_ExtString("viewer3d"));
mView = mViewer->CreateView();
// Set window for the view
mView->SetWindow(xw_window);
if (!xw_window->IsMapped()) {
xw_window->Map();
}
// Create AISInteractiveContext
mContext = new AIS_InteractiveContext(mViewer);
// Set up lights etc
mViewer->SetDefaultLights();
mViewer->SetLightOn();
mView->SetBackgroundColor(Quantity_NOC_BLACK);
mView->MustBeResized();
mView->TriedronDisplay(Aspect_TOTP_LEFT_LOWER, Quantity_NOC_GOLD, 0.08, V3d_ZBUFFER);
mContext->SetDisplayMode(AIS_Shaded, Standard_True);
// Call base method
Gtk::Widget::on_realize();
}
but the Gtk::Window stays empty after appending the OccView object. What am I doing wrong? Is there a working example on how to integrate the Opencascade V3d_View into a Gtk::Widget, or the gtkmm framework in general?
I haven't used GTK since university, so my experience is pretty basic here.
There are two basic approaches for embedding OpenGL-based viewer into GTK:
Ask OCCT to create OpenGL context for a native window taken from a normal Widget or entire window.
Wrap existing OpenGL context created by GUI library itself, e.g. Gtk::GLArea.
Your current code tries to follow the first approach used by conventional samples for Qt Widgets and MFC coming with OCCT. I guess it should be feasible, but implies some limitations and issues with mixing GTK widgets, as GTK will not be aware of OpenGL usage.
In contrast, Gtk::GLArea looks like a "modern" way for embedding OpenGL renderer designed by GTK developers and expected to work transparently.
Therefore, I've tried implementing a Hello-World sample using Gtk::GLArea (based on a development snapshot of OCCT 7.6.0dev):
https://github.com/gkv311/occt-samples-gtk
I don't bring the whole code of the sample here, as it is quite large in size.
Putting OCCT Viewer into Gtk::GLArea includes some tricky parts like:
Wrapping native Window into Aspect_Window (it could be also Xw_Window like in your sample, more general Aspect_NeutralWindow or another subclass).
Wrapping OpenGL context created by Gtk::GLArea into Aspect_RenderingContext/OpenGl_Context.
Wrapping offscreen buffer (FBO) used by Gtk::GLArea for rendering content into OpenGl_FrameBuffer.
Putting all viewer redraws into dedicated callback for Gtk::GLArea::signal_render().
Redirecting user input to viewer (with help of AIS_ViewController).
It is important to note, that GTK may be run in different context:
X11 server - X Window is created and GLX is used for OpenGL.
This is default OCCT configuration for Linux;
Wayland - native window is not X Window and EGL is used for OpenGL context.
OCCT does support EGL but as a dedicated configuration as alternative to GLX, while GTK handles this in runtime somehow. In addition, OCCT does not (yet) provide any wrapper for a Wayland native window, though it might be not critical for using.
GTK also has an option to use OpenGL ES instead of OpenGL.
Initially I expected Gtk::GLArea to work natively, but instead a very basic sample (without OCCT viewer) displays artifacts to me (widgets randomly blacked) on Xubuntu 18.04, though it works as expected on Ubuntu 21.04 (within Xorg session). I don't know if it is a bug fixed in GTK implementation, or there is something that should be fixed in a sample to workaround problem on older Linux.
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.
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 inspected the Qt GUI interfaces using window spy tools and I know that it does not use windows common controls or any custom window class to create its UI elements and animation effects. I asked before here about developing a custom GUI framework using GDI/GDI+ but most people responded against these technologies, so the question remains which graphics technology Qt or any other equivalent appropriator system uses to render their UI?
I am aware of DirectX/OpenGL but isn't it overkill for simple requirements? If the answer is going to be one of the above then again I wonder how one could implement robust font rendering and vector graphics solutions with these polygon rendering technology? the full featured text editor is another huge challenge.
Also there already exists solutions based on directx/opengl like MyGUI and CEGUI but I think they look ugly and nowhere near how Qt looks.
First things first, Qt-5 introduced a new rendering model, which can (but is not required to) use OpenGL for rendering the UI elements. The upshot of this is, that one can truly mix custom OpenGL rendering with Qt widgets. The downside is, that some kind of OpenGL support is required, which not all systems have.
So Qt also has these two other drawing systems: Native, which will use the hosts systems native graphics primitives (GDI, CoreGraphics, X11/XRender) and raster which does a complete rasterization of a whole window into pixel buffers, where then only those are blitted over to the underlying graphics system. raster is the slowest of the graphics backends, but it gives consistent results for all plattforms and target systems. Hence raster is usually used for programs where consistent appearance is strictly required.
When I browsed the source code of Qt I didn't find how it actually draws a GUI component, but I know it uses OpenGL.
I want to know how does a GUI library like Qt draw its GUI components (ex : QPushButton ,QWidget)?
Can any one help me with a basic idea ?
In Qt-project site :
Qt is painting QtWidgets using QPainter, which uses (usually) the raster engine to draw the content. It is not using native OS calls, apart from few exceptions (file dialog, for example, which can be drawn either natively or using QtWidgets).
QtQuick is painted using scenegraph, so OpenGL. Also, no native OS calls here.
I think you either misunderstood (there are several meanings of the word “native” in computing) the stackoverflow post, or your information source is wrong.
OK, then to be clear: by “native” I’ve meant using native OS controlls, like wxWidgets library does: asking the OS to draw native scroll bar, or combo box, etc. Qt does not do this. It paints all the widgets itself, and only tries to mimick the looks of the OS it is running on.
But obviously, some kind of native OS calling is happening deep inside, in order to actually draw some pixels on the screen, and open native window container. But that is usually not important at all to high level UI developers.
You have a clear choice whether the widget should be drawn by the CPU or the GPU: widgets can use different painting methods (native, raster, OpenGL, for more see here! [qt-project.org]), and the user has choice which one should be utilised. Most people do not use that, though, because the default settings work well.
Thanks.