yeah, You are very right, PC.
Listing here the headers that are being included in the source files may give us a hint of which GUI API is being used.
it is all about vtk:
#include <cstring>
#include <vector>
#include <vtkSTLReader.h>
#include <vtkMarchingCubes.h>
#include <vtkGlyph3D.h>
#include <vtkFixedPointVolumeRayCastMapper.h>
#include <vtkColorTransferFunction.h>
#include <vtkPiecewiseFunction.h>
#include <vtkVolumeProperty.h>
#include <vtkVolume.h>
#include <vtkRenderer.h>
#include <vtkRenderWindow.h>
#include <vtkRenderWindowInteractor.h>
#include <vtkImageMapToColors.h>
#include <vtkPolyDataMapper.h>
#include <vtkActor.h>
#include <vtkCutter.h>
#include <vtkPlane.h>
#include <vtkImageActor.h>
#include <vtkImageData.h>
#include <vtkImageCast.h>
#include <vtkPointData.h>
#include <vtkImageShiftScale.h>
#include <vtkPolyDataToImageStencil.h>
#include <vtkImageStencil.h>
#include <vtkLookupTable.h>
#include <vtkImagePlaneWidget.h>
#include <vtkCellArray.h>
#include <vtkType.h>
#include <vtkProperty.h>
#include <vtkCommand.h>
#include <vtkProbeFilter.h>
#include <vtkImplicitPlaneWidget.h>
#include <vtkClipPolyData.h>
#include <vtkSmartVolumeMapper.h>
#include <vtkInteractorStyleTrackballCamera.h>
#include <vtkInteractorStyleTrackballCamera.h>
#include <vtkCamera.h>
#include <vtkRendererCollection.h>
#include <vtkNamedColors.h>
#include <vtkPropPicker.h>
#include <vtkImplicitPlaneRepresentation.h>
#include <vtkImplicitPlaneWidget2.h>
#include <vtkAxesActor.h>
#include <vtkTextProperty.h>
#include <vtkCaptionActor2D.h>
#include <vtkTextActor.h>
#include <vtkCylinderSource.h>
#include <vtkAutoInit.h>
#include <vtkPointPicker.h>
#include <vtkCellPicker.h>
#include <vtkTransform.h>
#include <vtkLinearTransform.h>
#include <vtkAssembly.h>
#include <vtkOrientationMarkerWidget.h>
#include <vtkOutlineFilter.h>
#include <vtkVertex.h>
#include <vtkSphereSource.h>
#include <vtkMultiBlockDataSet.h>
#include <vtkCompositeDataGeometryFilter.h>
#include <vtkIntersectionPolyDataFilter.h>
#include <vtkParametricEllipsoid.h>
#include <vtkParametricFunctionSource.h>
#include <vtkLight.h>
#include <vtkTransformFilter.h>
#include <typeinfo>
Are those all the includes of all the source files in the program?
The same applies to other class files, which only contain vtk related files
If thatâs all, then youâre using a basic default GUI API, likely something GLUT-like. This makes pixel format mismatch unlikely. Then I believe you have to work out the other points discussed further above.
Yes, PC, following your suggestion, I called WaitForCompletion() and the frequency of this error indeed decreased. Iâm not sure if itâs just my perception, but it does seem to occur less often. I think it might be necessary for me to integrate this code into Qt and then address this errorďź
No, I donât think so. Try reducing your problem to a trivial case, that is, render to a single window and observe. Then enable a second window and observe and so on. You will reach a point when youâll get the errors. Then you need to add that check to avoid it.
One question you didnât answer is whether your program renderes from multiple threads. Is that so?
I show the windows like the code as follow, I think itâs single thread:
interactor_a->Initialize();
interactor_b->Initialize();
interactor_c->Initialize();
interactor_a->start();
interactor_b->start();
interactor_c->start();
Ok, right. Then try reducing your problem to a trivial case, that is, render to a single window and observe. Then enable a second window and observe and so on. You will reach a point when youâll get the errors. Then you need to add that check to avoid it.
yeah, thatâs a good method to adrress the error. I would try it.
Thank you very much, PC
From my experience, reducing to trivial case and proceed to cycles of slowly increasing complexity-and-observe is the best approach to tackle non-deterministic errors like that.
This is a valid approach, although it may be slow for my code because many global variables are shared among the windows to synchronize interactive operations. However, I will give it a try.
Thatâs a no-no in modern software design. You need additional care in presence of global variables. Better to try to get rid of them ASAP. There are better, modern approaches to system-wide notification mechanism such as signal-slots, functors, mutexes/semaphores and the Observer design parttern.
Yes, youâre rightďź PC. The synchronization issue with multiple window interaction has been troubling me for a while, and using global variables has proven to be a cumbersome and risky approach. I really appreciate your recommendations for better methods such as signal-slots, functors, mutexes/semaphores, and the Observer design pattern. I will search for resources to learn and apply these methods.
Since youâre not using Qt yet, I suggest you to take a look at Boostâs signals and slots. Please, take a look at this: Complete example using Boost::Signals for C++ Eventing - Stack Overflow
The Boost library is somewhat intimidating at first glance, but it is very well designed, it is peer-reviewed and almost as reliable as the C++ Standard Library itself. Actually, much of STL features were ported from Boost sometime.
Alternativelly, you may want to implement an Observer in your program: Understanding and Implementing Observer Pattern in C++ - CodeProject
Thank you so much, PC. The Observer pattern is indeed what Iâm looking for.
I will study the links you provided carefully. Thanks again!