Like DaBono said, you should have only one thread calling OpenGL functions.

Whether to use multiple threads for updating and rendering depends on what you want to achieve.

In an editor which doesn't require constant screen updates but rerenders the scene if something has changed or the window needs to be repainted, I'd say it is sufficient to have a single thread that alters your scene (geometry, camera position, etc.) and then renders it.

A game engine might want to have multiple threads. One could do AI and update an entity's position, speed etc., another could do physics simulation and update an object's position, orientation and even shape, while yet another thread handles data transfer, i.e. storing and loading data to and from disk (or other locations). Then you have one rendering thread that draws the scene and makes OpenGL calls. Of course you have to coordinate OpenGL calls for uploading data to video memory (you could have a copy of the data in system memory while loading it from disk, then granting access to the render thread which uploads it to video memory). With this approach you'd have multiple threads running distinct tasks at different frequencies (rendering being the fastest, then phyics simulation followed by AI and data transfer for example).

Well, afaik you could give the second thread a handle to the window and post a "(re)paint" message, but I don't have the details right now.

As for your textures: You could have copy of the textures in system memory, set a flag if this copy is altered, provide some information on which portion was altered and let the rendering thread upload the altered portion to OpenGL just before rendering.


Got some information now (from Windows Platform SDK):

SendMessage Function

--------------------------------------------------------------------------------

The SendMessage function sends the specified message to a window or windows. It calls the window procedure for the specified window and does not return until the window procedure has processed the message.

To send a message and return immediately, use the SendMessageCallback or SendNotifyMessage function. To post a message to a thread's message queue and return immediately, use the PostMessage or PostThreadMessage function.


Syntax

LRESULT SendMessage( HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam
);

PostMessage Function

The PostMessage function places (posts) a message in the message queue associated with the thread that created the specified window and returns without waiting for the thread to process the message.

To post a message in the message queue associate with a thread, use the PostThreadMessage function.


Syntax

BOOL PostMessage( HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam
);



I'd say PostMessage is the way to go with multithreading. Pass the HWND handle to your "external" thread and have it call PostMessage(hwnd, WM_PAINT, 0, 0) (wParam and lParam seem not be used here).

Quote:Original post by DaBono
My advise is to carefully look at the reasons why you would want multiple threads to call OpenGL. A cycle where you update objects, then render them might be sufficient and will save you the trouble of making things thread safe.

There can be reasons to have multiple game state update threads (like multiprocessor utilization, masochism, exercising a threading library, or peculiar architectural orientations), but the multiple threads don't really need to issue OpenGL calls.

For example, there can be a thread-safe queue where multiple threads post objects representing low-level and hopefully coarse-grained units of work (e.g. draw a triangle strip with a certain vertex buffer) as they compute them and a single thread executes the corresponding OpenGL calls.
Or for usually better performance, begin the drawing calls from a single special thread only after every state update thread is finished, so that whatever needs to be drawn can be sorted and collected in large batches and OpenGL calls can take place in a predictable order.

If performance is so limited by call overhead or bandwidth that one needs to start early and overlap OpenGL calls with updates, a humble optimization and redesign of the graphics is better than adopting complex multithreaded designs of dubious performance.

I'd say there shouldn't be a problem if both threads have access to the model's data unless you employ some locking mechanism.

Since PostMessage puts the message in the message queue of the window-owning thread this thread can re-render the scene whenever the data is ready (not locked). This thread should however be the only one to actually call OpenGL.