QThread data sharing method for GL vertex data - c++

Question

Let's say I want to render an animated triangle using two threads. One thread manipulates the vertices and the other one manages the QT window and renders the GL context. I have a class cTriangle, with members Eigen::Vector3d m_A, m_B, m_C representing the triangle vertices and a method void updateCoordinates() that operates on the vertices.
cTriangle.h:
#ifndef CTRIANGLE_H
#define CTRIANGLE_H
#include <Eigen/Core>
#include <QObject>
#include <vector>
class cTriangle : public QObject
{
Q_OBJECT
public:
cTriangle();
public:
Eigen::Vector3d m_A;
Eigen::Vector3d m_B;
Eigen::Vector3d m_C;
public slots:
void updateCoordinates();
};
#endif // CTRIANGLE_H
cTriangle.cpp:
#include "cTriangle.h"
#include <iostream>
cTriangle::cTriangle()
{
m_A = Eigen::Vector3d(0.0, 0.0, 0.0);
m_B = Eigen::Vector3d(0.2, 0.0, 0.0);
m_C = Eigen::Vector3d(0.0, 0.2, 0.0);
}
void cTriangle::updateCoordinates()
{
int ctr = 0;
double t = 0.0;
while (true)
{
std::cout << "cTriangle::updateCoordinates " << ctr << std::endl;
double offset = 0.3*sin(t);
m_A = Eigen::Vector3d(offset, 0.0, 0.0);
t += 0.00001;
ctr++;
}
}
The driver creates a new cTriangle and initiates a QThread, which continuously loops over updateCoordinates(). I also initialize the MainWindow containing a GLWidget.
main.cpp:
int main(int argc, char *argv[])
{
cTriangle* tri = new cTriangle();
QThread* thread = new QThread;
tri->moveToThread(thread);
QObject::connect(thread, SIGNAL(started()), tri, SLOT(updateCoordinates()) );
thread->start();
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
glwidget.h:
#ifndef GLWIDGET_H
#define GLWIDGET_H
#include <QGLWidget>
#include "cTriangle.h"
class GLWidget : public QGLWidget
{
Q_OBJECT
public:
explicit GLWidget(QWidget *parent = 0);
void initializeGL();
void resizeGL(int w, int h);
private:
signals:
void repaint();
public slots:
void paintGL();
};
#endif // GLWIDGET_H
glwidget.cpp:
GLWidget::GLWidget(QWidget *parent) : QGLWidget(parent)
{
}
void GLWidget::initializeGL()
{
glClearColor(0.2, 0.2, 0.2, 1);
}
void GLWidget::paintGL()
{
std::cout << "paintGL " << std::endl;
// ********************************
// How do I access Triangle data here??
// ********************************
glClear(GL_COLOR_BUFFER_BIT);
glLoadIdentity();
glBegin(GL_TRIANGLES);
glColor3f (1,0,0);
glVertex3f (0, -0.5, 0);
glColor3f (0,1,0);
glVertex3f (0.5, -0.5, 0);
glColor3f (0,0,1);
glVertex3f (0.0, 0.5, 0);
glEnd();
}
void GLWidget::resizeGL(int w, int h)
{}
Finally, my question: I need to access the vertex data in the object tri from within GLWidget::painGL. What is the best method for doing so? Setting up signal-slot functionality? Passing a pointer of tri in a thread-safe manner (if so, how?). This is just a toy example, generally the vertex data could be very large. Thanks!!
=============================
One step further:
My plan now is set set up a signal->signal->slot mechanics. GLWidget::glPaint() emits a SIGNAL GLWidget::requestVertices() to another SIGNAL cTriangle::sendVertices(whateverType vertexData), which is then received by SLOT GLWidget::receiveVertices(whateverType vertexData). In main.cpp, how do I CONNECT these signals? How do I get the reference to the GLWidget object? QObject::connect( ???, SIGNAL( requestVertices() ), tri, SIGNAL( sendVertices(double arg) ) );

Answer 1

Start by using the signal and slot mechanism. If you emit a signal with a QList of points, the QList uses implicit sharing, so will only copy-on-write.
This is the simplest method for using data across threads and doesn't require any handling of locks by you. If at some point you find this to be too slow, then you can look into optimising the code to improve the speed.
One possible method of optimisation would be to use multiple QList of points, so you write to one, then move on to writing to the next, while emitting the first, to ensure you're not writing to the list being shared and thus minimising the chance of a copy-on-write occurring.
However, there is no need to optimise, unless you're seeing a problem in the first place.