A thread for asynchronously processing OpenGL model updates. More...

#include <Rendering/OpenGL/wsglmodelprocessingthread.h>

Inheritance diagram for WSGLModelProcessingThread:

Public Types
using	ModelUpdatePtr = std::unique_ptr< WSGLModelUpdateInfo >

Public Member Functions
	WSGLModelProcessingThread ()

	WSGLModelProcessingThread (const WSGLModelProcessingThread &other)=delete

	~WSGLModelProcessingThread () override

std::future< ModelUpdatePtr >	enqueueUpdate (ModelUpdatePtr update)

bool	isStopRequested () const

WSGLModelProcessingThread &	operator= (const WSGLModelProcessingThread &)=delete

void	reset ()

void	run () override

void	stop ()

Public Member Functions inherited from BasicTextLogger
	BasicTextLogger ()

virtual	~BasicTextLogger ()

void	logLine (const Application::LogManager::MessageCategory &category, const QString &msg) const

void	logLine (const QString &msg) const

void	logText (const Application::LogManager::MessageCategory &category, const QString &msg) const

void	logText (const QString &msg) const

Detailed Description

In order to upload our OpenGL data, of which there are generally significant volumes, without blocking the main thread, we need an uploading thread and some synchronisation between this thread and the main thread. The main challenge in this specific case is that an OpenGL context belongs to a single thread, and it is not defined what occurs if one attempts to operate on a context from another thread.

Historically, we had been getting around this blocking problem by blocking the GUI thread using busy loops with QCoreApplication::processEvents() calls inside them; allowing paint events etc to be received while data was still being processed. Unfortunately, this caused flakiness in some cases, such as if a paint event switched OpenGL contexts while we were in in the middle of updating our data.

We can get around this requirement by memory-mapping the OpenGL memory we need to modify and passing it to our processing thread to modify. The processing thread then doesn't really need to care that it's uploading info to OpenGL - it only needs to care that it's writing data to a specific memory location. With some smart synchronisation, we can then return control back to the main thread when it next attempts to perform a render.

Member Typedef Documentation

◆ ModelUpdatePtr

using ModelUpdatePtr = std::unique_ptr<WSGLModelUpdateInfo>

Constructor & Destructor Documentation

◆ WSGLModelProcessingThread() [1/2]

WSGLModelProcessingThread ( )

◆ WSGLModelProcessingThread() [2/2]

WSGLModelProcessingThread ( const WSGLModelProcessingThread & other )

delete

◆ ~WSGLModelProcessingThread()

~WSGLModelProcessingThread ( )

overridedefault

Member Function Documentation

◆ enqueueUpdate()

std::future< WSGLModelProcessingThread::ModelUpdatePtr > enqueueUpdate ( ModelUpdatePtr update )

Parameters

update The update to enqueue on the processing thread

Enqueues a model update on the model processing thread. When completed, its results will be made available for retrieval via the returned future

◆ isStopRequested()

bool isStopRequested ( ) const

◆ operator=()

WSGLModelProcessingThread & operator= ( const WSGLModelProcessingThread & )

delete

◆ reset()

void reset ( )

◆ run()

void run ( )

override

◆ stop()

void stop ( )

Public Types

Public Member Functions