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.
Related
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'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.
Legacy QGLWidget could be integrated with rendering libraries (like SFML) by passing winId() result to the rendering library. But I can't make QOpenGLWidget work that way. After making it MainWindow's central widget I get series of warnings like QOpenGLWidget cannot be used as a native child widget. Consider setting Qt::AA_DontCreateNativeWidgetAncestors and Siblings.. Furthermore, the documentation says "QGLWidget on the other hand uses a native window and surface. (...) QOpenGLWidget avoids this by not creating a separate native window.". Can QOpenGLWidget be integrated with third party OpenGL software at all, or is it unsupported now?
You need to create a QWindow, initialize it and integrate into application with QWidget::createWindowContainer
class MyNativeWindow : QWindow
{
MyNativeWindow() : QWindow
{
setSurfaceType(QWindow::OpenGLSurface);
}
};
MyNativeWindow *nativeW = new MyNativeWindow();
QWidget *w = QWidget::createWindowContainer( nativeW );
// Use w as a simple QWidget
In some cases you don't need to use winId to get HWND. It is enough to know OpenGL context id. For custom gl context manipulation you may use QOpenGLContext class.
Be careful, because if your third party libraries will create native windows (in OS X) by themselves, you will have a lot of bugs with Qt. We are tied to fix bugs in our project. (Undockable docks, keyboard focus lost, impossibility of opening menus, errors with fullscreen etc.)
You may look at this code sample. And a custom context code sample.
I'm making an editor for 3d worlds in opengl using the windows forms UI. I'm developing on visual studio 2012 express and i would like to embed a GLFW window/context inside a windows form. just like done in this tutorial http://www.codeproject.com/Articles/16051/Creating-an-OpenGL-view-on-a-Windows-Form except working. And with GLFW for opengl context.
Is this possible? should i use Qt instead? and how would i got about doing this? I'm not bound to using windows forms i just need a simple good-looking functional UI for my project.
That are three different frameworks (Windows Forms, GLFW, Qt) which can all do the same thing, i.e. creating a window and an OpenGL context in it.
See here for an easy example how to create a window with OpenGL context with GLFW.
Or see here for the Qt example.
So, you have to choose between one of them. GLFW and Qt have the advantages that your code will also work on MacOSX and on Linux; with some work even on iPhone.
If you want to do the window creation and event handling and other stuff with GLFW but the GUI still with Qt, there is some way to do offline drawing (some ref here or here or here) the Qt widgets and then draw it onto some OpenGL texture. Or you might also be able to directly draw them via OpenGL (not exactly sure).
I'm using cocos2d-x to develop an iPhone game and then it just came to my head why not release my game for PC too? The only problem is that setting the window to full screen mode is not implemented yet. Now I'm just stuck with how to create a full screen window? There are some window creation functions that are used but I'm not sure which one and how I should change.
There is the eglCreateWindowSurface function that cocos2d is calling to create a window. I'm not sure which option I should change so that it creates a full screen window. It would also be nice if I can implement a function that switches my game to full screen mode and back while running.
On Windows it's a bit more compilicated. Essentially you have to:
Create a proxy OpenGL context to get access to functionality above OpenGL-1.1 through extensions
Load the extensions required to create an OpenGL-ES compatible context
Create the higher version OpenGL context
Again Load the extensions, now for this context
Luckily all this has been wrapped up in several easy to use libraries. I recomment GLFW for Window/Context creation (it deals with all that proxy context stuff, too), and GLee or GLEW to make the OpenGL extensions available to the code.
http://www.glfw.org/
http://elf-stone.com/glee.php
http://glew.sourceforge.net/
Those libraries are cross platform, so your application/game itself does not use OS dependent functions, it will compile not only for Windows but also Linux, BSD and MacOS X.