concepts threads

Thread Model

To maximize the experience, the rendering process should be as fluent as possible. However, some operations, like disk accesses or resource decoding, may take quite a long time. Therefore such operations should be moved to separate thread.

Render thread

This is the original thread, in which the map was created. It is used to render, navigate or change any configuration and should be fluent and responsive.

Methods Map::renderUpdate, Map::renderFinalize and Camera::renderUpdate should be called on this thread.

Note that none of these methods actually render anything and therefore do not require acces to OpenGL context.

Data thread

This thread is used for transferring the resources to the application.

Methods Map::dataUpdate and Map::dataFinalize should all be called on this thread.

Alternatively, the method Map::dataAllRun can replace both abovementioned methods and give control over the thread to the map. This is more cpu friendly, as the map will wake up the thread as needed only, instead of periodically checking if there is any work to be done. Note that the Map::dataAllRun will not return until Map::renderFinalize is called on another thread.

Render Context

The resource load* callbacks are called from the Map::dataUpdate, which is run on data thread. As those callbacks are used to pass the textures and meshes to the gpu, an OpenGL context needs to be bound on that thread. The best way is to have two OpenGL contexts that are configured to share resources. This works surprisingly good on desktop computers as well as on iPhones and iPads.

Naturally, this applies only when you use the vts rendering library too.

Content Fetcher

The browser is designed in a way such that the content fetcher may also use separate thread(s). You just pass the FetchTask to any thread and fill in the response. The FetchTask::fetchDone method can be called from any thread too.