Sun, 06/08/2025 - 00:34
In short: When already using a GUI toolkit such as Qt, why do OpenGl_GraphicDriver/OpenGl_Window etc still want access to things like native window handles, even when it's not responsible for creating any windows or GL contexts?
For example, the OpenGl_View does not seem to do anything useful unless OpenGl_View::SetWindow is called, which requires a native window handle.
I've integrated the viewer with a couple of toolkits so far, and I always run into issues because it tries to do stuff the GUI toolkit already does. As far as I know the only thing the graphics driver really needs is an OpenGL function loader, which could even be provided by the user, and for a suitable OpenGL context to be made current before it is asked to do things. The graphics driver could then be essentially entirely platform-independent. E.g. Aspect_DisplayConnection probably wouldn't be needed at all in this case.
Is there a reason there's such tight coupling between the graphics driver and various platform-specific APIs, beyond having the ability to create its own window if not using it inside an existing GUI toolkit?
Mon, 06/09/2025 - 15:04
TKOpenGlalready implements a very thin platform dependent layer.In the current implementation,
TKServiceis responsible for creation or passing through native window (Aspect_Windowinterface and it's subclasses likeWNT_Window). Notice that this layer doesn't depend on OpenGL and may create / wrap native windows for other graphic libraries.TKOpenGlimplements most functionally in platform-independent way. The major dependencies are: - OpenGL function pointers lookup (as you have pointed out); - Creation of OpenGL context for specified native window; - Swapchain management / mapping rendered content into the native window.It is possible wrapping existing native window with/without OpenGL context, but this is tricky due to complexity of platform-specific later and particular GUI framework (and some bugs in OCCT and/or GUI framework).
I can barely imagine what kind of simplification you bear in mind here - I suppose the objective is not simplification of implementation, but some API improvements. Maybe you may share particular suggestions?
Some commercial frameworks provide integration blocks for particular GUI frameworks as the part of their distribution (as extensions to main framework), but in case of OCCT these extensions will put a considerable extra maintenance burdain to OCCT developers.
Wed, 06/11/2025 - 19:40
I'm not talking easier as in adding e.g. Qt support into the core, but rather to get rid of the remaining platform dependent bits that can make the visualization slightly annoying to integrate. You're correct in that the platform integration is very thin - but still it reaches a bit too much into bits that it should not need to have access to (e.g. window handles) when integrated with an existing GUI toolkit.
What I'm specifically talking about are the
OpenGl_GraphicDriverconstructor which requiresAspect_DisplayConnectionandV3d_View::SetWindowwhich also wants some kind of native window handle. I haven't found out a way to get the thing to work without using those - if you know how, please let me know.What I'm thinking of is a mode where the only calls the rendering does is standard
glWhatevercalls. No checking for existence or validity of native windows, no creating contexts or swapping buffers. This would be up to the surrounding program. It would also be great to have GLX vs. EGL function loading as a runtime option rather than a compile time option, for redistributable binaries on Linux.I realize making this work actually reliably is tricky because of how global OpenGL state works, and it would depend on the GUI toolkit's behavior. This complexity would be outside of OCCT though.
I made a quick hacky version that disables the bit that I had problems with, if you're curious as to what it might look like:
https://github.com/mvirkkunen/OCCT/commit/9fda397bf2a3b46a4261cba3b4c7911c8cea0938