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 long time. Therefore such operations should be moved to separate thread.

The library is designed to work basically with two threads.

• The original thread, in which the map was created, also called render thread. It is used to render, navigate or change any configuration and should be fluent and responsive.
• The other thread, called data thread, is used for the time consuming tasks. It manages all resources, from downloading, through decoding to unloading.

Render Context

The resource load* callbacks are called from the 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. You may somehow lock the threads and rebound OpenGL context to the thread where it is needed, but that would cause a lot of overhead and long latencies, which is against the whole purpose of the data thread. A good solution 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.

Content Fetcher

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